-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying additonal web.xml snippet #577
Comments
US-613462 (internal) |
Can you please elaborate on the need for adding JMS resources in web.xml? Since web.xml resource does not go through many changes unlike context xml which goes through significant changes every release, we have not provided template version of web.xml and expect the user to mount the necessary changes/configurations as part of file. And also are you referring to https://github.com/pegasystems/pega-helm-charts/blob/master/charts/pega/config/deploy/tomcat-web.xml or web.xml from prweb archive? Based on our analysis we recommend you to mount web.xml from deploy/config folder. |
@PEGA-NarasimhaRao-Meda I'm referring to the web.xml in the prweb archive. If we use the deploy/config folder, then we're unable to use the chart from a remote repo and have to rely on local copies. This has a risk factor since each user of the charts needs to maintain their own copy of the distribution, and could easily lead to using an outdated version of the chart. The bigger problem is that every patch release someone should be analyzing the web.xml to see if the one being used in the deploy/config folder needs to be updated. Even if changes are infrequent, there's no way to know without checking. My suggestion is to support this in the docker image (no change to Helm charts needed) with this update to docker-entrypoint.sh:
The "adding snippet to web.xml" section is new and would simply add the contents of WEB_XML_SNIPPET, if that has been defined in the values file, at the end of the web.xml inside the closing tag. Users would define WEB_XML_SNIPPET in their values file the same way they can currently define CONTEXT_XML_SNIPPET. It would support uses cases including:
|
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 #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.
The text was updated successfully, but these errors were encountered: