RE: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
Hi, OK, Bernd Eckenfels' response was actually the one that was leading to the right direction: Mina obviously does not take the ed25519 algorithm from the JCE but from an external library: net.i2p.crypto eddsa 0.3.0 Adding this to the bundles installed by pax-exam into the osgi container may help. Best regards Stephan -Original Message- From: Steven Huypens Sent: Tuesday, 24 May 2022 15:29 To: dev@karaf.apache.org Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7 Hi Stephan, That is JDK 8 Steven On Tue, May 24, 2022 at 3:22 PM Siano, Stephan wrote: > Hi, > > Which JDK are you using for your pax-exam-tests? As far as I remember > ed25519 is only available in JDK 15 and later. > > Best regards > Stephan > > -Original Message- > From: Steven Huypens > Sent: Tuesday, 24 May 2022 14:51 > To: dev@karaf.apache.org > Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to > 4.3.7 > > I'm seeing the exact same log lines, so I'm interested to know as well. > > Kind regards, > Steven > > On Mon, May 23, 2022 at 3:52 PM Eric Lilja wrote: > > > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from > > Java > > 11 to Java 17. Now I can see the following warnings in the log when > > running Pax Exam tests: > > > > [INFO] 2022-05-23T15:33:43,050 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'sk-ssh-ed25...@openssh.com' not available > > [INFO] > > 2022-05-23T15:33:43,085 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'ssh-ed25519' not available [INFO] > > 2022-05-23T15:33:43,319 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'sk-ssh-ed25...@openssh.com' not available > > [INFO] > > 2022-05-23T15:33:43,320 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'ssh-ed25519' not available > > > > If I downgrade to 4.3.6, the warnings disappear. Looking at the > > changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1] > > > > How do I make the above warnings disappear? Is it a bug? The tests > > work fine, but it's a bit annoying to see these warnings. I'd rather > > not silence the logger, that seems wrong.. > > > > - Eric L >
Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
Hi Stephan, That is JDK 8 Steven On Tue, May 24, 2022 at 3:22 PM Siano, Stephan wrote: > Hi, > > Which JDK are you using for your pax-exam-tests? As far as I remember > ed25519 is only available in JDK 15 and later. > > Best regards > Stephan > > -Original Message- > From: Steven Huypens > Sent: Tuesday, 24 May 2022 14:51 > To: dev@karaf.apache.org > Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7 > > I'm seeing the exact same log lines, so I'm interested to know as well. > > Kind regards, > Steven > > On Mon, May 23, 2022 at 3:52 PM Eric Lilja wrote: > > > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from > > Java > > 11 to Java 17. Now I can see the following warnings in the log when > > running Pax Exam tests: > > > > [INFO] 2022-05-23T15:33:43,050 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > > 2022-05-23T15:33:43,085 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'ssh-ed25519' not available [INFO] > > 2022-05-23T15:33:43,319 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > > 2022-05-23T15:33:43,320 | WARN | activator-1-thread-1 | SshUtils > > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > > Configured signature 'ssh-ed25519' not available > > > > If I downgrade to 4.3.6, the warnings disappear. Looking at the > > changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1] > > > > How do I make the above warnings disappear? Is it a bug? The tests > > work fine, but it's a bit annoying to see these warnings. I'd rather > > not silence the logger, that seems wrong.. > > > > - Eric L >
RE: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
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
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
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-thr
Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
As far as I know the Eddsa variant Mina requires the external library, it is not yet ready to use JCE. Not sure if the sk- (Fido) variant is supported yet. Gruss Bernd -- https://bernd.eckenfels.net From: Siano, Stephan Sent: Tuesday, May 24, 2022 3:22:06 PM To: dev@karaf.apache.org Subject: RE: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7 Hi, Which JDK are you using for your pax-exam-tests? As far as I remember ed25519 is only available in JDK 15 and later. Best regards Stephan -Original Message- From: Steven Huypens Sent: Tuesday, 24 May 2022 14:51 To: dev@karaf.apache.org Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7 I'm seeing the exact same log lines, so I'm interested to know as well. Kind regards, Steven On Mon, May 23, 2022 at 3:52 PM Eric Lilja wrote: > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from > Java > 11 to Java 17. Now I can see the following warnings in the log when > running Pax Exam tests: > > [INFO] 2022-05-23T15:33:43,050 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > 2022-05-23T15:33:43,085 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available [INFO] > 2022-05-23T15:33:43,319 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > 2022-05-23T15:33:43,320 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available > > If I downgrade to 4.3.6, the warnings disappear. Looking at the > changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1] > > How do I make the above warnings disappear? Is it a bug? The tests > work fine, but it's a bit annoying to see these warnings. I'd rather > not silence the logger, that seems wrong.. > > - Eric L
RE: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
Hi, Which JDK are you using for your pax-exam-tests? As far as I remember ed25519 is only available in JDK 15 and later. Best regards Stephan -Original Message- From: Steven Huypens Sent: Tuesday, 24 May 2022 14:51 To: dev@karaf.apache.org Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7 I'm seeing the exact same log lines, so I'm interested to know as well. Kind regards, Steven On Mon, May 23, 2022 at 3:52 PM Eric Lilja wrote: > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from > Java > 11 to Java 17. Now I can see the following warnings in the log when > running Pax Exam tests: > > [INFO] 2022-05-23T15:33:43,050 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > 2022-05-23T15:33:43,085 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available [INFO] > 2022-05-23T15:33:43,319 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO] > 2022-05-23T15:33:43,320 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available > > If I downgrade to 4.3.6, the warnings disappear. Looking at the > changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1] > > How do I make the above warnings disappear? Is it a bug? The tests > work fine, but it's a bit annoying to see these warnings. I'd rather > not silence the logger, that seems wrong.. > > - Eric L
Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
I'm seeing the exact same log lines, so I'm interested to know as well. Kind regards, Steven On Mon, May 23, 2022 at 3:52 PM Eric Lilja wrote: > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from Java > 11 to Java 17. Now I can see the following warnings in the log when running > Pax Exam tests: > > [INFO] 2022-05-23T15:33:43,050 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available > [INFO] 2022-05-23T15:33:43,085 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available > [INFO] 2022-05-23T15:33:43,319 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'sk-ssh-ed25...@openssh.com' not available > [INFO] 2022-05-23T15:33:43,320 | WARN | activator-1-thread-1 | SshUtils > | 55 - org.apache.karaf.shell.ssh - 4.3.7 | > Configured signature 'ssh-ed25519' not available > > If I downgrade to 4.3.6, the warnings disappear. Looking at the changelog > for 4.3.7, I suppose this is caused by KARAF-7363 [1] > > How do I make the above warnings disappear? Is it a bug? The tests > work fine, but it's a bit annoying to see these warnings. I'd rather not > silence the logger, that seems wrong.. > > - Eric L > > [1] https://issues.apache.org/jira/browse/KARAF-7363 >
Re: [UPDATE] Apache Karaf runtime 4.4.0 during the week end
Hi JB, Will there be a 4.2.16 release? *Regards* *Vignesh* On Tue, 12 Apr 2022 at 09:13, Jean-Baptiste Onofré wrote: > By the way, I forgot to mention that I will submit 4.3.7 and 4.2.16 to vote > as well. > > So we will have three votes by the end of week. > > Regards > JB > > Le lun. 11 avr. 2022 à 09:54, Jean-Baptiste Onofré a > écrit : > > > Hi guys, > > > > Quick update about Karaf 4.4.0. It's almost ready to be submitted to > > vote. We would need xbean 4.21 and aries proxy release, but they are > > not blocker for the release. > > > > I propose to complete the current set and move forward with the 4.4.0 > > release. > > > > I will keep you posted later today or tomorrow. > > > > Regards > > JB > > > > On Tue, Apr 5, 2022 at 5:33 AM Jean-Baptiste Onofré > > wrote: > > > > > > Hi Robert, > > > > > > I'm almost good with 4.4.0. > > > I should be able to submit the vote by the end of the week (merging > > > last PRs and triage some Jira). > > > > > > Regards > > > JB > > > > > > On Tue, Apr 5, 2022 at 12:01 AM Robert Varga wrote: > > > > > > > > On 21/03/2022 13:54, Jean-Baptiste Onofré wrote: > > > > > Hi guys, > > > > > > > > Hello JB, > > > > > > > > > I found a couple of minor issues that I'm working on right now. > > > > > I will submit 4.4.0 release to vote asap. > > > > > > > > sorry to be a bother, but is there an update on this effort? > > > > > > > > The reason I am asking is we need KARAF-7401 to be able to require > > JDK17 > > > > in OpenDaylight. Unless there is a Karaf release with that fix (4.3.x > > or > > > > 4.4.x, either works) available in about a week (integration deadline > is > > > > 15.4., we can push that out by a week or two, but not more) we will > > need > > > > to push that transition out by 6 months :( > > > > > > > > Thanks, > > > > Robert > > >
Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
Hello
wt., 24 maj 2022 o 09:59 Siano, Stephan
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-3na#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-3na#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 whe
Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
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-3na#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-3na#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
