Skip to content
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

Open
maracle6 opened this issue Jun 6, 2023 · 3 comments
Open

Specifying additonal web.xml snippet #577

maracle6 opened this issue Jun 6, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@maracle6
Copy link
Contributor

maracle6 commented Jun 6, 2023

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.

@maracle6 maracle6 added the enhancement New feature or request label Jun 6, 2023
@kishorv10
Copy link
Contributor

US-613462 (internal)

@PEGA-NarasimhaRao-Meda
Copy link
Contributor

@maracle6

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.

@maracle6
Copy link
Contributor Author

maracle6 commented May 28, 2024

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?

@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:

#
# Copying mounted web.xml file to conf
#
if [ -e "${web_xml}" ]; then
  echo "Loading web.xml from ${web_xml}...";
  cp "${web_xml}" "${PEGA_DEPLOYMENT_DIR}/WEB-INF/"
else
  echo "No web.xml was specified in ${web_xml}. Using defaults."
fi

#
# Adding snippet to web.xml
#
if [ -n "$WEB_XML_SNIPPET" ]; then
  echo "Inserting WEB_XML_SNIPPET into web.xml";
  awk -v var="$WEB_XML_SNIPPET" '/<\/web-app>/ {print var;} 1' ${PEGA_DEPLOYMENT_DIR}/WEB-INF/web.xml > /tmp/web.xml && mv /tmp/web.xml ${PEGA_DEPLOYMENT_DIR}/WEB-INF/web.xml
fi

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:

  • Add an additional servlet
  • Add a security constraint
  • Add JMS resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants