Hello
wt., 24 maj 2022 o 09:59 Siano, Stephan <stephan.si...@sap.com.invalid>
napisał(a):
> 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!
>
It was my pleasure refactoring ;) I'd never have written/designed anything
as complex as Pax Web in the first place, so big thanks to original authors!
> 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()
>
These are kind of inline dev notes. I can imagine that they may blur the
code, but I really tried to ensure that everything is consistent, so I
spent a lot of time reading the original Tomcat/Jetty/Undertow code and
writing down some observations.
This note just states what Tomcat itself is doing and it uses it for
$CATALINA_HOME/conf/context.xml file which is common to ALL web
applications. That's definitely something we DON'T want in Pax Web.
> 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?
>
While the default org.ops4j.pax.web PID created when you install
pax-web-http-tomcat feature contains:
#org.ops4j.pax.web.config.file = ${karaf.etc}/tomcat-server.xml
and sample tomcat-server.xml is provided, that's more natural to be treated
as "global" configuration. I'd like to avoid handling external context.xml
for all WABs.
>
> 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
Yes - and `/META-INF/context.xml` is searched using
org.osgi.framework.Bundle#findEntries() (search without using classloaders,
include fragments), additional search is performed for all non-jar entries
from Bundle-ClassPath headers - just to make it clear that first
org.osgi.framework.Bundle#findEntries() doesn't return
/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.
>
and actually you're right - I've explicitly searched for context.xml in
multiple locations, but didn't use it when actually applying the
configuration. The check is needed to not include for example Jetty's
WEB-INF/jetty-web.xml when using Tomcat, but simple change from:
if (path.equals("/META-INF/context.xml")) {
to:
if (path.endsWith("/META-INF/context.xml")) {
is probably what we need.
>
> I am willing to contribute to this, but I would prefer to discuss the
> correct way to go first.
>
I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1721 to
track this issue - thanks!
And while I've checked, I can immediately fix it ;)
kind regards
Grzegorz Grzybek
> Best regards
> Stephan
>
