pega-helm-charts icon indicating copy to clipboard operation
pega-helm-charts copied to clipboard

Specifying additonal web.xml snippet

Open maracle6 opened this issue 2 years ago • 3 comments

Is your feature request related to a problem? Please describe. To configure a JMS Listener, we need to add tags to web.xml. Currently we have to pass in the entire web.xml in custom.webXML in our values.yaml. The web.xml is over 1600 lines, needs to be added to each tier, and to be safe we need to update it on every release since there could be some change to the one in prweb.war.

We need a way to pass in the web.xml updates more easily.

Describe the solution you'd like For our use case, where we simply need to add a snippet inside the tag of web.xml, I'd like to be able to supply a parameter custom.env.WEB_XML_SNIPPET, which would then be inserted into the web.xml by the docker entrypoint script. This would pair with the custom.env.CONTEXT_XML_SNIPPET that already exists (see https://github.com/pegasystems/pega-helm-charts/issues/121).

Describe alternatives you've considered The Helm chart allows for a web.xml to be placed in the deploy/config directory of the chart, but this then means that the chart is specific to a particular application and isn't generic for use with any values.yaml.

The existing custom.webXML capability to pass in the entire file could be more convenient if it supported an external secret. That way, you wouldn't need to embed the 1600 line web.xml in your values.yaml. However if there's any update to the OOTB web.xml in a patch or new minor release we would need to identify the change and update our secret properly. This at best adds additional work to every update, and at worst could lead to use of an incorrect web.xml. For use cases where we're only adding to the web.xml it's preferable to insert a snippet at runtime.

We also considered whether specifying specific changes to context.xml and web.xml makes sense for end users that just want to implement JMS. Currently we need to have some understanding of the internals of Pega's docker image. Maybe there could be a more abstract way to describe JMS resources and references, and the Helm code determines how to turn those elements into changes to the appropriate config files in the runtime image. We don't know if it's feasible to do this in an abstract way and still support all possible JMS integrations.

maracle6 avatar Jun 06 '23 17:06 maracle6

US-613462 (internal)

kishorv10 avatar Apr 29 '24 07:04 kishorv10