Hi Grzegorz,
> 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.
Well, this global context.xml in Tomcat is for customizing all web applications
to the environment. This might as well be a use case for the karaf container.
Currently some of the stuff like authentication configuration is hard-coded in
the pax-web-tomcat coding, however we need to find a way to customize this
somehow...
Best regards
Stephan
-----Original Message-----
From: Grzegorz Grzybek <gr.grzy...@gmail.com>
Sent: Tuesday, 24 May 2022 11:44
To: dev@karaf.apache.org
Subject: Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
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.Bundl
> eWebApplication##anonymous#wab-extender-1-thread-3####na#na#na#na#Foun
> d
> 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.Bundl
> eWebApplication##anonymous#wab-extender-1-thread-3####na#na#na#na#Foun
> d
> 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.OsgiContex
> tConfiguration##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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fops4j%2Forg.ops4j.pax.web%2Fissues%2F1721&data=05%7C01%7Cstephan.siano%40sap.com%7C4b4f6ea5d9a44673243008da3d69f2fb%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637889823523653497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TjyNQhD718rmu5bnlbVieloWvNMh1eFb9VQn34%2BMtXk%3D&reserved=0
to track this issue - thanks!
And while I've checked, I can immediately fix it ;)
kind regards
Grzegorz Grzybek
> Best regards
> Stephan
>
