Re: Memory leak in EncodingDetector?
Hi Chris
Spring's ObservationFilterChainDecorator is ridiculous, isn't it?
> What if you create an empty jaxp.properties file and make it available to the
> common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) -- does that
> prevent the problem?
I think that boils down to what I'm already doing with the system
property, getting to the FactoryFinder before it uses
findServiceProvider(). Haven't tried it, but I'm sure it would work.
imho, Tomcat's EncodingDetector should init with either
XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();
to just always use the JVM XMLInputFactory, or then
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
to honor it's own classloader (maybe
EncodingDetector.class.getClassLoader() is the wrong approach,
basically something getTomcatCommonClassloader())
What I just don't get is why there's so little online about others
havingEncodingDetector similar issues. Spring + libs like CXF or
jackson-dataformat-xml are common, both those libs have transitive
dependencies on woodstox-core. Throw in ehcache, also common, and your
webapp won't undeploy if it's the first webapp to load a JSP and thus
clinit EncodingDetector. Maybe the public has just given up on clean
undeploying.
Simon
Mühlegasse 18, 6340 Baar, Switzerland
https://www.want.ch
https://www.funnel.travel
On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
wrote:
>
> Simon,
>
> On 3/20/24 09:59, Simon Niederberger wrote:
> > The whole thing is caused by Maven dependencies which pull in
> > com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
> >
> > @ServiceProvider(XMLInputFactory.class)
> >
> > annotation, where ServiceProvider is
> > org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
> > key code section, but I do find that the
> > javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
> > as registered service provider. As WstxInputFactory is not on the
> > common classpath (it's in WEB-INF/lib), I assume it's the webapp
> > classloader which is used. Below is the stacktrace where
> > EncodingDetector clinit happens (I defined a
> > ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
> > stacktraces):
> >
> > Currently I'm setting
> >
> > System.setProperty("javax.xml.stream.XMLInputFactory",
> > "com.sun.xml.internal.stream.XMLInputFactoryImpl");
> > to get a XMLInputFactory implementation which is on the common
> > loader's classpath, so the webapp can be undeployed cleanly.
>
> So this works, right?
>
> What if you create an empty jaxp.properties file and make it available
> to the common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties)
> -- does that prevent the problem?
>
> I'm wondering if Tomcat should simply ship with an empty jaxp.properties
> file to prevent this kind of thing from happening by default. If someone
> wants to bundle an XMLInputFactory into Tomcat's lib/ directory and use
> that, they could remove this file.
>
> BTW that's an impressive stack trace. ;)
>
> -chris
>
> > java.lang.RuntimeException: Stracktrace for tracking XMLInputFactory
> > creation
> > at
> > ch.want.funnel.FunnelApp$DelegatingXMLInputFactory.(FunnelApp.java:107)
> > at
> > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> > at
> > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > at
> > java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> > at
> > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> > at
> > java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:190)
> > at
> > java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:148)
> > at
> > java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:261)
> > at
> > java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:223)
> > at
> > java.xml/javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:166)
> > at
> > org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
> > at
> > org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
> > at
> > org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
> > at
> > org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
> > at
> > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
> > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:396)
> > at org.apache.jasper.compiler.Compiler.compile(Compiler.jav
Re: Memory leak in EncodingDetector?
Simon,
On 3/20/24 09:59, Simon Niederberger wrote:
The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
@ServiceProvider(XMLInputFactory.class)
annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):
Currently I'm setting
System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
to get a XMLInputFactory implementation which is on the common
loader's classpath, so the webapp can be undeployed cleanly.
So this works, right?
What if you create an empty jaxp.properties file and make it available
to the common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties)
-- does that prevent the problem?
I'm wondering if Tomcat should simply ship with an empty jaxp.properties
file to prevent this kind of thing from happening by default. If someone
wants to bundle an XMLInputFactory into Tomcat's lib/ directory and use
that, they could remove this file.
BTW that's an impressive stack trace. ;)
-chris
java.lang.RuntimeException: Stracktrace for tracking XMLInputFactory creation
at
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory.(FunnelApp.java:107)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:190)
at
java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:148)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:261)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:223)
at
java.xml/javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:166)
at
org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
at
org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
at
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
at
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:396)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:372)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:356)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108)
at
org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231)
at
org.springframework.security.web.ObservationFilterChainDecorator$FilterObservation$SimpleFilterObservation.lambda$wrap$1(ObservationFilterChainDecorator.
Re: Memory leak in EncodingDetector?
Hi Chris
The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
@ServiceProvider(XMLInputFactory.class)
annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):
Currently I'm setting
System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
to get a XMLInputFactory implementation which is on the common
loader's classpath, so the webapp can be undeployed cleanly.
Best regards
Simon
--
java.lang.RuntimeException: Stracktrace for tracking XMLInputFactory creation
at
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory.(FunnelApp.java:107)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:190)
at
java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:148)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:261)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:223)
at
java.xml/javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:166)
at
org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
at
org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
at
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
at
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:396)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:372)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:356)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
at
org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108)
at
org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231)
at
org.springframework.security.web.ObservationFilterChainDecorator$FilterObservation$SimpleFilterObservation.lambda$wrap$1(ObservationFilterChainDecorator.java:479)
at
org.springframework.security.web.ObservationFilterChainDecorator$AroundFilterObservation$SimpleAroundFilterObservation.lambda$wrap$1(ObservationFilterChainDecorator.java:340)
at
org.springframework.security.web.ObservationFilterChainDecorator.lambda$wrapSecured$0(ObservationFilterChainDecorator.java:82)
at
org.springframework.security.web.ObservationFilterChainDecorator$VirtualFilterChain.doFilter(ObservationFilterChainDecorator.java:128)
at
org.springframework.security.web.access.intercept.AuthorizationFilter
Re: What future plans are for Tomcat authentication
On 20/03/2024 06:22, Mircea Butmalai wrote: Questions are: 1. Is Jakarta Authentication specification going to replace the authentication part of Jakarta Servlet specification? Unlikely. 2. Are current authenticatiors from Tomcat (FORM, SPNEGO, SSL, HTTP DIGEST, HTTP BASIC, SSO) going to be implemented as Jakarta Authentication providers in future versions of Tomcat? This has been discussed in the past but there is little motivation to do so as there are no obvious benefits and possible negative performance impacts. 3. Is any effort to introduce in Jakarta standards + Tomcat an authentcator of type 2FA? No plans I am aware of. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
