Hi,
I have been trying around with Karaf 4.4.0 with the pax-web-tomcat webcontainer
in the last days. First of all I want to state that Grzegorz did a fantastic
job with the Pax-Web refactoring!
Nevertheless, I encountered a few issues with tomcat context.xml handling.
First of all prior versions of pax-web-tomcat were able to load a default
context.xml from the same directory as the tomcat-server.xml. I am not sure how
to proceed with this.
The BundleWebApplication class in the pax-web-extender-war bundle contains the
following comment:
// additionally:
// - Tomcat handles context.xml files set by
org.apache.catalina.core.StandardContext.setDefaultContextXml()
However, as far as I understand, the defaultContextXml in StandardContext is
not used in the embedded Tomcat. The only uses I could find was in the
org.apache.catalina.startup.ContextConfig.contextConfig() method which does not
seem to get called by the embedded tomcat startup. This method is normally
called with a ContextConfig.lifecycleEvent(Lifecycle.AFTER_INIT_EVENT), but it
seems that this ContextConfig lifecycle is not called. I am not sure what is
the way to go here, either to try to include this ContextConfig lifecycle, try
to exeute the contextConfig method with the digester we get in the
TomcatFactory.createContextDigester() method, or try to funnel this default
context.xml somehow into the serverSpecificDescriptors and parse it in the
tomcat specific OsgiContextConfiguration class. What do you think?
The code does support context.xml files in WARs. The context.xml files are
found within a war by the BundleWebApplication class and forwarded as
serverSpecificDescriptors to the web container implementation. These
descriptors are applied in class
org.ops4j.pax.web.service.tomcat.internal.OsgiContextConfiguration. However,
the war extender will find context files both in /META-INF/context.xml and
/WEB-INF/classes/META-INF/context.xml (actually it will find any invocation of
/META-INF/context.xml in the bundle’s classpath), whereas the
OsgiContextConfiguration class explicitly limits this to
path.equals("/META-INF/context.xml") which will include the first but exclude
the second location. I am not sure if this is correct (but it seems a bit odd
to me). This results in the logs below:
2022 05 23
14:37:26#+00#DEBUG#org.ops4j.pax.web.extender.war.internal.model.BundleWebApplication##anonymous#wab-extender-1-thread-3####na#na#na#na#Found
Tomcat-specific descriptor:
bundle://2157ae21-cf1a-4966-8b3e-c768aaacf073_230.0:0/META-INF/context.xml|
2022 05 23
14:37:26#+00#DEBUG#org.ops4j.pax.web.extender.war.internal.model.BundleWebApplication##anonymous#wab-extender-1-thread-3####na#na#na#na#Found
Tomcat-specific descriptor:
bundle://2157ae21-cf1a-4966-8b3e-c768aaacf073_230.0:0/WEB-INF/classes/META-INF/context.xml|
2022 05 23
14:37:26#+00#INFO#org.ops4j.pax.web.service.tomcat.internal.OsgiContextConfiguration##anonymous#paxweb-config-3-thread-1
(deploy /auth)####na#na#na#na#Processing context specific
bundle://2157ae21-cf1a-4966-8b3e-c768aaacf073_230.0:0/META-INF/context.xml for
/auth|
Is that behavior correct? It might probably be a good idea to relax the filter
in OsgiContextConfiguration a bit.
I am willing to contribute to this, but I would prefer to discuss the correct
way to go first.
Best regards
Stephan
