Re: Tomcat 10.1 Upgrade & Uber JAR Error
Looks like this last worked Tomcat v10.1.20 and first failed v19.1.23 On Fri, Feb 7, 2025 at 3:22 PM Tim N wrote: > I was launching my application successfully with Tomcat 10.1.16 using a > JAR with all dependencies in a single JAR via "maven-assembly-plugin". > > Since upgrading to Tomcat 10.1.34, one of my applications is now throwing > > java.lang.NullPointerException: Cannot invoke > "org.apache.jasper.compiler.TldCache.getTldResourcePath(String)" because > the return value of "org.apache.jasper.Options.getTldCache()" is null > > The JARs are: > commons-codec-1.15.jar > ecj-3.33.0.jar > tomcat-annotations-api-10.1.34.jar > tomcat-api-10.1.34.jar > tomcat-catalina-10.1.34.jar > tomcat-catalina-ha-10.1.34.jar > tomcat-coyote-10.1.34.jar > tomcat-el-api-10.1.34.jar > tomcat-embed-core-10.1.34.jar > tomcat-embed-el-10.1.34.jar > tomcat-embed-jasper-10.1.34.jar > tomcat-embed-websocket-10.1.34.jar > tomcat-jaspic-api-10.1.34.jar > tomcat-jdbc-10.1.34.jar > tomcat-jni-10.1.34.jar > tomcat-jsp-api-10.1.34.jar > tomcat-juli-10.1.34.jar > tomcat-servlet-api-10.1.34.jar > tomcat-tribes-10.1.34.jar > tomcat-util-10.1.34.jar > tomcat-util-scan-10.1.34.jar > > Any ideas why this would be a problem with a more recent version? > >
Tomcat 10.1 Upgrade & Uber JAR Error
I was launching my application successfully with Tomcat 10.1.16 using a JAR with all dependencies in a single JAR via "maven-assembly-plugin". Since upgrading to Tomcat 10.1.34, one of my applications is now throwing java.lang.NullPointerException: Cannot invoke "org.apache.jasper.compiler.TldCache.getTldResourcePath(String)" because the return value of "org.apache.jasper.Options.getTldCache()" is null The JARs are: commons-codec-1.15.jar ecj-3.33.0.jar tomcat-annotations-api-10.1.34.jar tomcat-api-10.1.34.jar tomcat-catalina-10.1.34.jar tomcat-catalina-ha-10.1.34.jar tomcat-coyote-10.1.34.jar tomcat-el-api-10.1.34.jar tomcat-embed-core-10.1.34.jar tomcat-embed-el-10.1.34.jar tomcat-embed-jasper-10.1.34.jar tomcat-embed-websocket-10.1.34.jar tomcat-jaspic-api-10.1.34.jar tomcat-jdbc-10.1.34.jar tomcat-jni-10.1.34.jar tomcat-jsp-api-10.1.34.jar tomcat-juli-10.1.34.jar tomcat-servlet-api-10.1.34.jar tomcat-tribes-10.1.34.jar tomcat-util-10.1.34.jar tomcat-util-scan-10.1.34.jar Any ideas why this would be a problem with a more recent version?
RE: RE: JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
I've replicated something similar on Tomcat 10.1.34 (and also 9.0.98). Steps
1 - Download and unzip Tomcat 10.1.34
2 - Create file "webapps/ROOT/include.jsp" with contents "I've been
included!"
3 - Edit "webapps/ROOT/index.jsp" adding the following code at the bottom
of the JSP
```
<%
String bigString = "This is a big
string";
for (int i = 0; i < 100; i++) {
bigString += "This is a big
string";
}
request.setAttribute("bigString", bigString);
request.setAttribute("length", bigString.length());
%>
isCommitted=<%= response.isCommitted() %>
${bigString}
length=${length/1024}
isCommitted=<%= response.isCommitted() %>
Before Include
After Include
```
3 - Start Tomcat (using Java 17)
4 - Load page http://localhost:8080/
5 - The text "I've been included!" is missing
One thing I've noticed, if I change the loop from 100 to 10 the included
content is included. Then if I change it back to 100 without restarting,
the included content is still included.
RE: JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
Just an update...I eliminated the tiles and spring:theme code, and still get the error by putting the same large content in the page with ". Again, this is resolved by increasing the buffer size. I've also noticed the response is marked as committed with the large output before the "jsp:include". This doesn't seem to be an issue in Tomcat 9, but does seem to be in Tomcat 10.
Re: JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
Yep. I also checked that, so I'm not sure where the problem could be either. > Please provide a ready to use test case. That will be time-consuming, but I'll see what I can do. If you can think of any check I can do with the existing code, that would be great (and possibly easier/quicker). On Thu, Jan 30, 2025 at 3:16 AM Rémy Maucherat wrote: > On Wed, Jan 29, 2025 at 5:45 AM Tim N wrote: > > > > I'm including the stack-trace in case that's helpful > > There are no differences in JspWriterImpl between 9.0 and the current > Tomcat 11 or 12 trunk. > > The buffer of the writer will auto flush by default if it is full. > This is the "autoFlush" on the page directive of the JSP. I don't > understand why it would not work. Also the default value of autoFlush > has not changed. > > Please provide a ready to use test case. > > Rémy > > > Note references to tiles is for the Jakarta EE upgraded tiles at > > https://github.com/tntim96/tiles/tree/jakarta-upgrade > > > > writeMessage:385, MessageTag (org.springframework.web.servlet.tags) > > doEndTag:285, MessageTag (org.springframework.web.servlet.tags) > > _jspx_meth_spring_005ftheme_005f2:406, default_005ftemplate_jsp > > (org.apache.jsp.WEB_002dINF.templates) > > _jspService:405, default_005ftemplate_jsp > (org.apache.jsp.WEB_002dINF.templates) > > service:70, HttpJspBase (org.apache.jasper.runtime) > > service:658, HttpServlet (jakarta.servlet.http) > > service:456, JspServletWrapper (org.apache.jasper.servlet) > > serviceJspFile:380, JspServlet (org.apache.jasper.servlet) > > service:328, JspServlet (org.apache.jasper.servlet) > > service:658, HttpServlet (jakarta.servlet.http) > > internalDoFilter:205, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:149, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:51, WsFilter (org.apache.tomcat.websocket.server) > > internalDoFilter:174, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:149, ApplicationFilterChain (org.apache.catalina.core) > > lambda$doFilterInternal$3:231, FilterChainProxy > > (org.springframework.security.web) > > doFilter:-1, FilterChainProxy$$Lambda$2217/0x000802473210 > > (org.springframework.security.web) > > doFilter:365, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:100, AuthorizationFilter > > (org.springframework.security.web.access.intercept) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:126, ExceptionTranslationFilter > > (org.springframework.security.web.access) > > doFilter:120, ExceptionTranslationFilter > > (org.springframework.security.web.access) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:62, SiteSecurityAuthFilter (mycode.grants.site.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:100, AnonymousAuthenticationFilter > > (org.springframework.security.web.authentication) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:78, ClusteredConcurrentSessionFilter > (mycode.grants.core.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:179, SecurityContextHolderAwareRequestFilter > > (org.springframework.security.web.servletapi) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:63, RequestCacheAwareFilter > > (org.springframework.security.web.savedrequest) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:78, CSPApplyFilter (mycode.grants.site.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:227, AbstractAuthenticationProcessingFilter > > (org.springframework.security.web.authentication) > > doFilter:221, AbstractAuthenticationProcessingFilter > > (org.springframework.security.web.authentication) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:107, LogoutFilter > > (org.springframework.security.web.authentication.logout) > > doFilter:93, LogoutFilter > > (org.springframework.security.web.authentication.logout) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:88, ConcurrentLoginFilter (mycode.grants
Re: JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
It is a stack-trace generated from a break-point that I thought might be useful. On Thu, Jan 30, 2025 at 12:13 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Tim, > > Your original post says there is no error, so what exactly is this a > stack-trace OF? > > -chris > > On 1/28/25 11:43 PM, Tim N wrote: > > I'm including the stack-trace in case that's helpful > > > > Note references to tiles is for the Jakarta EE upgraded tiles at > > https://github.com/tntim96/tiles/tree/jakarta-upgrade > > > > writeMessage:385, MessageTag (org.springframework.web.servlet.tags) > > doEndTag:285, MessageTag (org.springframework.web.servlet.tags) > > _jspx_meth_spring_005ftheme_005f2:406, default_005ftemplate_jsp > > (org.apache.jsp.WEB_002dINF.templates) > > _jspService:405, default_005ftemplate_jsp > (org.apache.jsp.WEB_002dINF.templates) > > service:70, HttpJspBase (org.apache.jasper.runtime) > > service:658, HttpServlet (jakarta.servlet.http) > > service:456, JspServletWrapper (org.apache.jasper.servlet) > > serviceJspFile:380, JspServlet (org.apache.jasper.servlet) > > service:328, JspServlet (org.apache.jasper.servlet) > > service:658, HttpServlet (jakarta.servlet.http) > > internalDoFilter:205, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:149, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:51, WsFilter (org.apache.tomcat.websocket.server) > > internalDoFilter:174, ApplicationFilterChain (org.apache.catalina.core) > > doFilter:149, ApplicationFilterChain (org.apache.catalina.core) > > lambda$doFilterInternal$3:231, FilterChainProxy > > (org.springframework.security.web) > > doFilter:-1, FilterChainProxy$$Lambda$2217/0x000802473210 > > (org.springframework.security.web) > > doFilter:365, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:100, AuthorizationFilter > > (org.springframework.security.web.access.intercept) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:126, ExceptionTranslationFilter > > (org.springframework.security.web.access) > > doFilter:120, ExceptionTranslationFilter > > (org.springframework.security.web.access) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:62, SiteSecurityAuthFilter (mycode.grants.site.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:100, AnonymousAuthenticationFilter > > (org.springframework.security.web.authentication) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:78, ClusteredConcurrentSessionFilter > (mycode.grants.core.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:179, SecurityContextHolderAwareRequestFilter > > (org.springframework.security.web.servletapi) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:63, RequestCacheAwareFilter > > (org.springframework.security.web.savedrequest) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:78, CSPApplyFilter (mycode.grants.site.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:227, AbstractAuthenticationProcessingFilter > > (org.springframework.security.web.authentication) > > doFilter:221, AbstractAuthenticationProcessingFilter > > (org.springframework.security.web.authentication) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:107, LogoutFilter > > (org.springframework.security.web.authentication.logout) > > doFilter:93, LogoutFilter > > (org.springframework.security.web.authentication.logout) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:88, ConcurrentLoginFilter (mycode.grants.site.security) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:58, WaitingRoomFilter (mycode.grants.site.web) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) > > doFilter:75, CSRFSameOriginHeaderCheckFilter (mycode.common.web) > > doFilter:374, FilterChainProxy$VirtualFilterChain > > (org.springframework.security.web) &
RE: JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
I'm including the stack-trace in case that's helpful Note references to tiles is for the Jakarta EE upgraded tiles at https://github.com/tntim96/tiles/tree/jakarta-upgrade writeMessage:385, MessageTag (org.springframework.web.servlet.tags) doEndTag:285, MessageTag (org.springframework.web.servlet.tags) _jspx_meth_spring_005ftheme_005f2:406, default_005ftemplate_jsp (org.apache.jsp.WEB_002dINF.templates) _jspService:405, default_005ftemplate_jsp (org.apache.jsp.WEB_002dINF.templates) service:70, HttpJspBase (org.apache.jasper.runtime) service:658, HttpServlet (jakarta.servlet.http) service:456, JspServletWrapper (org.apache.jasper.servlet) serviceJspFile:380, JspServlet (org.apache.jasper.servlet) service:328, JspServlet (org.apache.jasper.servlet) service:658, HttpServlet (jakarta.servlet.http) internalDoFilter:205, ApplicationFilterChain (org.apache.catalina.core) doFilter:149, ApplicationFilterChain (org.apache.catalina.core) doFilter:51, WsFilter (org.apache.tomcat.websocket.server) internalDoFilter:174, ApplicationFilterChain (org.apache.catalina.core) doFilter:149, ApplicationFilterChain (org.apache.catalina.core) lambda$doFilterInternal$3:231, FilterChainProxy (org.springframework.security.web) doFilter:-1, FilterChainProxy$$Lambda$2217/0x000802473210 (org.springframework.security.web) doFilter:365, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:100, AuthorizationFilter (org.springframework.security.web.access.intercept) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:126, ExceptionTranslationFilter (org.springframework.security.web.access) doFilter:120, ExceptionTranslationFilter (org.springframework.security.web.access) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:62, SiteSecurityAuthFilter (mycode.grants.site.security) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:100, AnonymousAuthenticationFilter (org.springframework.security.web.authentication) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:78, ClusteredConcurrentSessionFilter (mycode.grants.core.security) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:179, SecurityContextHolderAwareRequestFilter (org.springframework.security.web.servletapi) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:63, RequestCacheAwareFilter (org.springframework.security.web.savedrequest) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:78, CSPApplyFilter (mycode.grants.site.security) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:227, AbstractAuthenticationProcessingFilter (org.springframework.security.web.authentication) doFilter:221, AbstractAuthenticationProcessingFilter (org.springframework.security.web.authentication) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:107, LogoutFilter (org.springframework.security.web.authentication.logout) doFilter:93, LogoutFilter (org.springframework.security.web.authentication.logout) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:88, ConcurrentLoginFilter (mycode.grants.site.security) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:58, WaitingRoomFilter (mycode.grants.site.web) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:75, CSRFSameOriginHeaderCheckFilter (mycode.common.web) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:110, OncePerRequestFilter (org.springframework.web.filter) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:281, SiteSecurityFilter (mycode.grants.site.security) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:41, SessionTrackingFilter (mycode.common.web) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:75, SecurityContextHolderFilter (org.springframework.security.web.context) doFilter:69, SecurityContextHolderFilter (org.springframework.security.web.context) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:110, OncePerRequestFilter (org.springframework.web.filter) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:133, ChannelProcessingFilter (org.springframework.security.web.access.channel) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilter:110, OncePerRequestFilter (org.springframework.web.filter) doFilter:374, FilterChainProxy$VirtualFilterChain (org.springframework.security.web) doFilterInternal:233, Filte
JspWriterImpl BufferSize And Flushing In Tomcat 10.1.16
I am migrating from SpringBoot 2.7.18 to 3.0.13 with the accompanying migration from Tomcat 9.0.83 to 10.1.16. I am trying to render a large message, around 8kB. In Tomcat 9, the content renders correctly, In Tomcat 10 the content doesn't render at all, and there's no error message. I noticed if I make the content smaller, it does render correctly. Leaving the content too big to render in Tomcat 10, I debugged down to... org/springframework/web/servlet/tags/MessageTag.doEndTag ...and noticed "this.pageContext.getOut()" returns "org.apache.jasper.runtime.JspWiterImpl". I also noticed the buffer size was 8192, which should be irrelevant. However, I've noticed if I set the following JSP directive at the top of the page, it renders OK <%@ page buffer="32kb" %> Has something broken JspWriterImpl? I've tried upgrading to Tomcat 10.1.34 which doesn't resolve the issue. Thoughts?
Re: Did something JSP related change between 9.0.71 and 9.0.73
One last note on this...we noticed some pages not fixed after upgrading New Relic, but fixed them by deleting the compiled JSP files (e.g. files in work/Tomcat/my-webapp/ROOT/org/apache/jsp/WEB_002dINF/jsp) and letting Tomcat re-compile them. On Mon, Sep 4, 2023 at 12:48 AM அருள்ராஜன் அ லை wrote: > Yes. It is with some JASPER library changes in Tomcat which affected the > NewRelic agents. It was fixed in NewRelic agent 8.2.0. In our case we have > newrelic agent 7,4.x ., So it failed. > > For a temporary measure we disabled the new relic browser monitoring and > moved on. (Ours is not a UI app) > > You can check the fixes section of release notes > > https://docs.newrelic.com/docs/release-notes/agent-release-notes/java-release-notes/java-agent-820/ > > https://github.com/newrelic/newrelic-java-agent/pull/1225 > > வெள்., 1 செப்., 2023, பிற்பகல் 3:02 அன்று, Tim N > எழுதியது: > > > Fixed by upgrading New Relic to 8.5.0! > > > > Other environments had this upgraded, but not the failing one. > > > > On Fri, Sep 1, 2023 at 5:26 PM Torsten Krah wrote: > > > > > Am Freitag, dem 01.09.2023 um 15:18 +1000 schrieb Tim N: > > > > We're seeing this too, but not in all our environments. We also use > > > > NewRelic. > > > > > > Does it happen without NewRelic too? If not, better ask NewRelic about > > > that problem. > > > > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > -- > நன்றி, > அருள். >
Re: Did something JSP related change between 9.0.71 and 9.0.73
Fixed by upgrading New Relic to 8.5.0! Other environments had this upgraded, but not the failing one. On Fri, Sep 1, 2023 at 5:26 PM Torsten Krah wrote: > Am Freitag, dem 01.09.2023 um 15:18 +1000 schrieb Tim N: > > We're seeing this too, but not in all our environments. We also use > > NewRelic. > > Does it happen without NewRelic too? If not, better ask NewRelic about > that problem. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Did something JSP related change between 9.0.71 and 9.0.73
We're seeing this too, but not in all our environments. We also use NewRelic. JSP Previously rendered to Now renders to /path/style.css"/> Affected Tomcat version is 9.0.78
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
> This should be unnecessary. The classes in that package should be
> included in tomcat-embed-core
Nice - thanks. I was reading and using the catalina code, but after
trimming down my code it no longer needs that dependency.
Do you think this thread is useful info for any Tomcat-embedded Java 17
migration guide/how-to? I'm happy to tidy it up and contribute if there's
an official Tomcat-embedded place for it.
> The Java code looks good to me. The calls to
> SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader()
> may be unnecessary
Looks like I can ditch the SecurityClassLoad.securityClassLoad() call, but
without the Service.setParentClassLoader() call I get classloading errors,
specifically:
Dec 23, 2022 1:47:00 PM org.apache.catalina.core.StandardContext
listenerStart
SEVERE: Error configuring application listener of class
[org.springframework.web.context.request.RequestContextListener]
java.lang.ClassNotFoundException:
org.springframework.web.context.request.RequestContextListener
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1412)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:534)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:515)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:149)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4687)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5222)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
at
java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
at
java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
Do you think I need to look into that more, or does it make sense that the
Service.setParentClassLoader() prevents this?
On Thu, Dec 22, 2022 at 9:49 PM Mark Thomas wrote:
> On 21/12/2022 22:37, Tim N wrote:
> > This was fixed by adding "--add-opens=java.base/java.lang=ALL-UNNAMED".
> Now
> > all applications are running, and various other issues have been fixed by
> > other "--add-opens" arguments. So these and the last couple of issues are
> > related to Java 17 and not the classloader code above.
> >
> > Can a Tomcat expert comment on the approach and code to customise the
> > classpath as per the thread topic - I'll repeat here for clarity:
> > Add Dependency:
> >
> >
> > org.apache.tomcat
> > tomcat-catalina
> > ${tomcat.version}
> >
>
> This should be unnecessary. The classes in that package should be
> included in tomcat-embed-core
>
>
> > Java
>
>
>
> The Java code looks good to me. The calls to
> SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader()
> may be unnecessary but I don't think they'll cause any harm.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
This was fixed by adding "--add-opens=java.base/java.lang=ALL-UNNAMED". Now
all applications are running, and various other issues have been fixed by
other "--add-opens" arguments. So these and the last couple of issues are
related to Java 17 and not the classloader code above.
Can a Tomcat expert comment on the approach and code to customise the
classpath as per the thread topic - I'll repeat here for clarity:
Add Dependency:
org.apache.tomcat
tomcat-catalina
${tomcat.version}
Java
List repositories = new ArrayList<>();
repositories.add(new ClassLoaderFactory.Repository(new
File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
repositories.add(new ClassLoaderFactory.Repository(new
File("sub-mod1/target/classes").getAbsolutePath(),
ClassLoaderFactory.RepositoryType.DIR));
repositories.add(new ClassLoaderFactory.Repository(new
File("sub-mod2/target/classes").getAbsolutePath(),
ClassLoaderFactory.RepositoryType.DIR));
File[] files = new File("lib-runtime").listFiles();
for (File file : files) {
repositories.add(new ClassLoaderFactory.Repository(file.getAbsolutePath(),
ClassLoaderFactory.RepositoryType.JAR));
}
ClassLoader myClassLoader =
ClassLoaderFactory.createClassLoader(repositories, null);
Thread.currentThread().setContextClassLoader(myClassLoader);
SecurityClassLoad.securityClassLoad(myClassLoader);
...
Tomcat tomcat = new Tomcat();
tomcat.getService().setParentClassLoader(myClassLoader);
On Wed, Dec 21, 2022 at 4:20 PM Tim N wrote:
> After sorting out the new dependencies (I think) 2 of the 3 web-apps are
> now running!
>
> One fails at startup with
> Caused by: java.lang.LinkageError: loader java.net.URLClassLoader
> @2328c243 attempted duplicate class definition for
> mypackage.MyUserDetailsService$$EnhancerBySpringCGLIB$$f761e392.
> (mypackage.MyUserDetailsService$$EnhancerBySpringCGLIB$$f761e392 is in
> unnamed module of loader java.net.URLClassLoader @2328c243, parent loader
> 'app')
> at java.base/java.lang.ClassLoader.defineClass0(Native Method)
> at java.base/java.lang.System$2.defineClass(System.java:2307)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2439)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2416)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.defineClass(MethodHandles.java:1843)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor71.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:576)
>
>
> On Wed, Dec 21, 2022 at 3:33 PM Tim N wrote:
>
>> Sorry - more of the stack-trace:
>> Caused by: java.lang.IllegalAccessError: failed to access class
>> com.sun.activation.registries.LogSupport from class
>> javax.activation.MimetypesFileTypeMap
>> (com.sun.activation.registries.LogSupport and
>> javax.activation.MimetypesFileTypeMap are in unnamed module of loader
>> java.net.URLClassLoader @2328c243)
>> at
>> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:100)
>> at
>> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:271)
>> at
>> org.springframework.mail.javamail.ConfigurableMimeFileTypeMap.createFileTypeMap(ConfigurableMimeFileTypeMap.java:150)
>>
>> On Wed, Dec 21, 2022 at 3:28 PM Tim N wrote:
>>
>>> I tried this:
>>>
>>> List repositories = new ArrayList<>();
>>> repositories.add(new ClassLoaderFactory.Repository(new
>>> File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
>>> repositories.add(new ClassLoaderFactory.Repository(new
>>> File("sub-mod1/target/classes").getAbsolutePath(),
>>> ClassLoaderFactory.RepositoryType.DIR));
>>> repositories.add(new ClassLoaderFactory.Repository(new
>>> File("sub-mod2/target/classes").getAbsolutePath(),
>>> ClassLoaderFactory.RepositoryType.DIR));
>>> File[] files = new File("lib-runtime").listFiles();
>>> for (File file : files) {
>>> repositories.add(new
>>> ClassLoaderFactory.Repository(file.getAbsolutePath(),
>>> ClassLoaderFactory.RepositoryType.JAR));
>>> }
>>>
>>> ClassLoader myClassLoader =
>>> ClassLoaderFactory.createClassLoader(repositories, null);
>>>
>>> Thread.currentThread().setContextClassLoader(myClassLoader);
>>> SecurityClassLoad.se
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
After sorting out the new dependencies (I think) 2 of the 3 web-apps are
now running!
One fails at startup with
Caused by: java.lang.LinkageError: loader java.net.URLClassLoader @2328c243
attempted duplicate class definition for
mypackage.MyUserDetailsService$$EnhancerBySpringCGLIB$$f761e392.
(mypackage.MyUserDetailsService$$EnhancerBySpringCGLIB$$f761e392 is in
unnamed module of loader java.net.URLClassLoader @2328c243, parent loader
'app')
at java.base/java.lang.ClassLoader.defineClass0(Native Method)
at java.base/java.lang.System$2.defineClass(System.java:2307)
at
java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2439)
at
java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2416)
at
java.base/java.lang.invoke.MethodHandles$Lookup.defineClass(MethodHandles.java:1843)
at java.base/jdk.internal.reflect.GeneratedMethodAccessor71.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:576)
On Wed, Dec 21, 2022 at 3:33 PM Tim N wrote:
> Sorry - more of the stack-trace:
> Caused by: java.lang.IllegalAccessError: failed to access class
> com.sun.activation.registries.LogSupport from class
> javax.activation.MimetypesFileTypeMap
> (com.sun.activation.registries.LogSupport and
> javax.activation.MimetypesFileTypeMap are in unnamed module of loader
> java.net.URLClassLoader @2328c243)
> at
> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:100)
> at
> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:271)
> at
> org.springframework.mail.javamail.ConfigurableMimeFileTypeMap.createFileTypeMap(ConfigurableMimeFileTypeMap.java:150)
>
> On Wed, Dec 21, 2022 at 3:28 PM Tim N wrote:
>
>> I tried this:
>>
>> List repositories = new ArrayList<>();
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("sub-mod1/target/classes").getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.DIR));
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("sub-mod2/target/classes").getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.DIR));
>> File[] files = new File("lib-runtime").listFiles();
>> for (File file : files) {
>> repositories.add(new
>> ClassLoaderFactory.Repository(file.getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.JAR));
>> }
>>
>> ClassLoader myClassLoader =
>> ClassLoaderFactory.createClassLoader(repositories, null);
>>
>> Thread.currentThread().setContextClassLoader(myClassLoader);
>> SecurityClassLoad.securityClassLoad(myClassLoader);
>> ...
>> Tomcat tomcat = new Tomcat();
>> tomcat.getService().setParentClassLoader(myClassLoader);
>>
>> And am currently getting this:
>> java.util.concurrent.ExecutionException:
>> org.apache.catalina.LifecycleException: Failed to start component
>> [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
>> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>> at
>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:923)
>> at
>> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
>> at
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>> at
>> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
>> at
>> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
>> at
>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
>> at
>> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
>&g
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
Looks like this is due to a conflict with EE JARs added to replace those
removed when moving from Java 8 to 17.
On Wed, Dec 21, 2022 at 3:33 PM Tim N wrote:
> Sorry - more of the stack-trace:
> Caused by: java.lang.IllegalAccessError: failed to access class
> com.sun.activation.registries.LogSupport from class
> javax.activation.MimetypesFileTypeMap
> (com.sun.activation.registries.LogSupport and
> javax.activation.MimetypesFileTypeMap are in unnamed module of loader
> java.net.URLClassLoader @2328c243)
> at
> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:100)
> at
> javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:271)
> at
> org.springframework.mail.javamail.ConfigurableMimeFileTypeMap.createFileTypeMap(ConfigurableMimeFileTypeMap.java:150)
>
> On Wed, Dec 21, 2022 at 3:28 PM Tim N wrote:
>
>> I tried this:
>>
>> List repositories = new ArrayList<>();
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("sub-mod1/target/classes").getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.DIR));
>> repositories.add(new ClassLoaderFactory.Repository(new
>> File("sub-mod2/target/classes").getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.DIR));
>> File[] files = new File("lib-runtime").listFiles();
>> for (File file : files) {
>> repositories.add(new
>> ClassLoaderFactory.Repository(file.getAbsolutePath(),
>> ClassLoaderFactory.RepositoryType.JAR));
>> }
>>
>> ClassLoader myClassLoader =
>> ClassLoaderFactory.createClassLoader(repositories, null);
>>
>> Thread.currentThread().setContextClassLoader(myClassLoader);
>> SecurityClassLoad.securityClassLoad(myClassLoader);
>> ...
>> Tomcat tomcat = new Tomcat();
>> tomcat.getService().setParentClassLoader(myClassLoader);
>>
>> And am currently getting this:
>> java.util.concurrent.ExecutionException:
>> org.apache.catalina.LifecycleException: Failed to start component
>> [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
>> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>> at
>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:923)
>> at
>> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
>> at
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>> at
>> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
>> at
>> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
>> at
>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
>> at
>> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at
>> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
>>
>> So the code looks closer to working, but still something major wrong.
>>
>> On Wed, Dec 21, 2022 at 11:02 AM Tim N wrote:
>>
>>> > The custom class loader approach described in one of the answers is a
>>> > viable option.
>>>
>>> Thanks.
>>>
>>> > No. The same class loader hierarchy isn't constructed when running in
>>> > embedded mode.
>>>
>>> It looks like I would need to replicate all the classloading
>>> capabilities of Tomcat (e.g. loading classes from files and JARs). Any tips
>>> for implementing this?
>>>
>>> It looks like the Tomcat classloader code is available via
>>> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina.
>>> This isn't a tomcat-embedded module, but looks like it might be compatible.
>>>
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
Sorry - more of the stack-trace:
Caused by: java.lang.IllegalAccessError: failed to access class
com.sun.activation.registries.LogSupport from class
javax.activation.MimetypesFileTypeMap
(com.sun.activation.registries.LogSupport and
javax.activation.MimetypesFileTypeMap are in unnamed module of loader
java.net.URLClassLoader @2328c243)
at
javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:100)
at
javax.activation.MimetypesFileTypeMap.(MimetypesFileTypeMap.java:271)
at
org.springframework.mail.javamail.ConfigurableMimeFileTypeMap.createFileTypeMap(ConfigurableMimeFileTypeMap.java:150)
On Wed, Dec 21, 2022 at 3:28 PM Tim N wrote:
> I tried this:
>
> List repositories = new ArrayList<>();
> repositories.add(new ClassLoaderFactory.Repository(new
> File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
> repositories.add(new ClassLoaderFactory.Repository(new
> File("sub-mod1/target/classes").getAbsolutePath(),
> ClassLoaderFactory.RepositoryType.DIR));
> repositories.add(new ClassLoaderFactory.Repository(new
> File("sub-mod2/target/classes").getAbsolutePath(),
> ClassLoaderFactory.RepositoryType.DIR));
> File[] files = new File("lib-runtime").listFiles();
> for (File file : files) {
> repositories.add(new
> ClassLoaderFactory.Repository(file.getAbsolutePath(),
> ClassLoaderFactory.RepositoryType.JAR));
> }
>
> ClassLoader myClassLoader =
> ClassLoaderFactory.createClassLoader(repositories, null);
>
> Thread.currentThread().setContextClassLoader(myClassLoader);
> SecurityClassLoad.securityClassLoad(myClassLoader);
> ...
> Tomcat tomcat = new Tomcat();
> tomcat.getService().setParentClassLoader(myClassLoader);
>
> And am currently getting this:
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:923)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
>
> So the code looks closer to working, but still something major wrong.
>
> On Wed, Dec 21, 2022 at 11:02 AM Tim N wrote:
>
>> > The custom class loader approach described in one of the answers is a
>> > viable option.
>>
>> Thanks.
>>
>> > No. The same class loader hierarchy isn't constructed when running in
>> > embedded mode.
>>
>> It looks like I would need to replicate all the classloading capabilities
>> of Tomcat (e.g. loading classes from files and JARs). Any tips for
>> implementing this?
>>
>> It looks like the Tomcat classloader code is available via
>> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina.
>> This isn't a tomcat-embedded module, but looks like it might be compatible.
>> Could these classes be used to achieve what I'm after? If I could get this
>> working, I could maybe contribute back with "how-to" documentation.
>> Thoughts?
>>
>> Also, how do I make embedded Tomcat use my classloader?
>>
>>
>> On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas wrote:
>>
>>> On 14/12/2022 03:20, Tim N wrote:
>>> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
>>> > infamous compatibility issue with ClassLoader.getSystem
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
I tried this:
List repositories = new ArrayList<>();
repositories.add(new ClassLoaderFactory.Repository(new
File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
repositories.add(new ClassLoaderFactory.Repository(new
File("sub-mod1/target/classes").getAbsolutePath(),
ClassLoaderFactory.RepositoryType.DIR));
repositories.add(new ClassLoaderFactory.Repository(new
File("sub-mod2/target/classes").getAbsolutePath(),
ClassLoaderFactory.RepositoryType.DIR));
File[] files = new File("lib-runtime").listFiles();
for (File file : files) {
repositories.add(new ClassLoaderFactory.Repository(file.getAbsolutePath(),
ClassLoaderFactory.RepositoryType.JAR));
}
ClassLoader myClassLoader =
ClassLoaderFactory.createClassLoader(repositories, null);
Thread.currentThread().setContextClassLoader(myClassLoader);
SecurityClassLoad.securityClassLoad(myClassLoader);
...
Tomcat tomcat = new Tomcat();
tomcat.getService().setParentClassLoader(myClassLoader);
And am currently getting this:
java.util.concurrent.ExecutionException:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:923)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
So the code looks closer to working, but still something major wrong.
On Wed, Dec 21, 2022 at 11:02 AM Tim N wrote:
> > The custom class loader approach described in one of the answers is a
> > viable option.
>
> Thanks.
>
> > No. The same class loader hierarchy isn't constructed when running in
> > embedded mode.
>
> It looks like I would need to replicate all the classloading capabilities
> of Tomcat (e.g. loading classes from files and JARs). Any tips for
> implementing this?
>
> It looks like the Tomcat classloader code is available via
> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina.
> This isn't a tomcat-embedded module, but looks like it might be compatible.
> Could these classes be used to achieve what I'm after? If I could get this
> working, I could maybe contribute back with "how-to" documentation.
> Thoughts?
>
> Also, how do I make embedded Tomcat use my classloader?
>
>
> On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas wrote:
>
>> On 14/12/2022 03:20, Tim N wrote:
>> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
>> > infamous compatibility issue with ClassLoader.getSystemClassLoader when
>> > upgrading from Java 8 to Java 17.
>> > See
>> >
>> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
>> > for a good summary.
>>
>> The custom class loader approach described in one of the answers is a
>> viable option.
>>
>> > Is it possible to utilise and modify the Tomcat classloader hierarchy
>> for
>> > embedded Tomcat to add to the classpath, specifically:
>> > - Add some shared libraries as done with the 'shared.loader' for
>> Tomcat
>> > for production and development environments
>>
>> No. The same class loader hierarchy isn't constructed when running in
>> embedded mode.
>>
>> > - Add another module's classes to the classpath for a web-app for
>> > development environment only (e.g. add "../sub-module/target/classes" to
>> > classpath)
>>
>> Yes. Each web applicatio
Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
> The custom class loader approach described in one of the answers is a
> viable option.
Thanks.
> No. The same class loader hierarchy isn't constructed when running in
> embedded mode.
It looks like I would need to replicate all the classloading capabilities
of Tomcat (e.g. loading classes from files and JARs). Any tips for
implementing this?
It looks like the Tomcat classloader code is available via
https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina. This
isn't a tomcat-embedded module, but looks like it might be compatible.
Could these classes be used to achieve what I'm after? If I could get this
working, I could maybe contribute back with "how-to" documentation.
Thoughts?
Also, how do I make embedded Tomcat use my classloader?
On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas wrote:
> On 14/12/2022 03:20, Tim N wrote:
> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
> > infamous compatibility issue with ClassLoader.getSystemClassLoader when
> > upgrading from Java 8 to Java 17.
> > See
> >
> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
> > for a good summary.
>
> The custom class loader approach described in one of the answers is a
> viable option.
>
> > Is it possible to utilise and modify the Tomcat classloader hierarchy for
> > embedded Tomcat to add to the classpath, specifically:
> > - Add some shared libraries as done with the 'shared.loader' for Tomcat
> > for production and development environments
>
> No. The same class loader hierarchy isn't constructed when running in
> embedded mode.
>
> > - Add another module's classes to the classpath for a web-app for
> > development environment only (e.g. add "../sub-module/target/classes" to
> > classpath)
>
> Yes. Each web application still retains its own class loader. You
> configure the web application resources to map static resources, JARs
> and/or directories of classes to the right place in your web app.
>
> For example (totally untested but should give you the idea):
>
> Tomcat tomcat = new Tomcat();
> Context context = tomcat.addContext("", "/some/path");
> WebResourceRoot root = context.getResources();
> DirResourceSet extraJARs = new DirResourceSet(root,
> "/WEB-INF/lib", "/path/to/extra/jars", "");
> root.addPostResources(extraJARs);
>
> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader', but
> > that is no longer possible in Java 9+.
> >
> > Is there any official documentation for this?
>
> The docs for configuring this in context.xml are here:
>
> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>
> Javadoc for doing it directly is here:
>
>
> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>
> HTH,
>
> Mark
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17
I'm currently using embedded Tomcat 9.0.68 and have encountered the infamous compatibility issue with ClassLoader.getSystemClassLoader when upgrading from Java 8 to Java 17. See https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader for a good summary. Is it possible to utilise and modify the Tomcat classloader hierarchy for embedded Tomcat to add to the classpath, specifically: - Add some shared libraries as done with the 'shared.loader' for Tomcat for production and development environments - Add another module's classes to the classpath for a web-app for development environment only (e.g. add "../sub-module/target/classes" to classpath) In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader', but that is no longer possible in Java 9+. Is there any official documentation for this?
Tomcat 9.0.N SimpleTcpCluster Max Cluster Sizing
>From the official documentation "The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, you should use the BackupManager" Any ideas on what the limit is or how to measure it? Any good articles?
Tomcat 9.0.N Upgrading Minor Version In A Cluster
Will session fail-over work b/w minor versions? i.e. can you cycle through upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68? Also, is there any official documentation on this?
Re: Tomcat 9.0.37 Clustered DeltaManager Duplicates Session And Loses Session Attributes
> The second seems to the result of a cluster message received which seems
odd on the machine where the session is being created
I think this was the issue. I've changed:
StaticMembershipInterceptor interceptor = new StaticMembershipInterceptor();
int clusterMemberCount =
Integer.parseInt(serverProperties.getProperty("tomcat-clusterMemberCount"));
{
StaticMember localMember = new StaticMember();
localMember.setPort(port);
localMember.setSecurePort(-1);
localMember.setHost(serverProperties.getProperty("tomcat-clusterAddress"));
localMember.setDomain("publish-cluster");
localMember.setUniqueId(serverProperties.getProperty("tomcat-clusterMemberUniqueId"));
interceptor.setLocalMember(localMember);
interceptor.addStaticMember(localMember);//Removed
}
...to...
StaticMembershipInterceptor interceptor = new StaticMembershipInterceptor();
int clusterMemberCount =
Integer.parseInt(serverProperties.getProperty("tomcat-clusterMemberCount"));
{
StaticMember localMember = new StaticMember();
localMember.setLocal(true);//Added
localMember.setPort(port);
localMember.setSecurePort(-1);
localMember.setHost(serverProperties.getProperty("tomcat-clusterAddress"));
localMember.setDomain("publish-cluster");
localMember.setUniqueId(serverProperties.getProperty("tomcat-clusterMemberUniqueId"));
interceptor.setLocalMember(localMember);
}
...and it seems to be fine now.
On Fri, Oct 9, 2020 at 12:26 PM Tim N wrote:
> Here's the two stack traces, in order of occurrence, for the DeltaSession
> creation. The second seems to the result of a cluster message received
> which seems odd on the machine where the session is being created:
>
> :109, DeltaSession (org.apache.catalina.ha.session)
> createEmptySession:471, DeltaManager (org.apache.catalina.ha.session)
> createSession:708, ManagerBase (org.apache.catalina.session)
> createSession:422, DeltaManager (org.apache.catalina.ha.session)
> createSession:410, DeltaManager (org.apache.catalina.ha.session)
> doGetSession:3043, Request (org.apache.catalina.connector)
> getSession:2441, Request (org.apache.catalina.connector)
> getSession:908, RequestFacade (org.apache.catalina.connector)
> getSession:920, RequestFacade (org.apache.catalina.connector)
> getSession:253, HttpServletRequestWrapper (javax.servlet.http)
> getSession:253, HttpServletRequestWrapper (javax.servlet.http)
> getSession:253, HttpServletRequestWrapper (javax.servlet.http)
> onAuthentication:66, RegisterSessionAuthenticationStrategy
> (org.springframework.security.web.authentication.session)
> doFilter:218, AbstractAuthenticationProcessingFilter
> (org.springframework.security.web.authentication)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:200, AbstractAuthenticationProcessingFilter
> (org.springframework.security.web.authentication)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:116, LogoutFilter
> (org.springframework.security.web.authentication.logout)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilterInternal:74, HeaderWriterFilter
> (org.springframework.security.web.header)
> doFilter:119, OncePerRequestFilter (org.springframework.web.filter)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:74, CSRFSameOriginHeaderCheckFilter (ourcompany.common.web)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:36, SessionTrackingFilter (ourcompany.common.web)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:105, SecurityContextPersistenceFilter
> (org.springframework.security.web.context)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilterInternal:56, WebAsyncManagerIntegrationFilter
> (org.springframework.security.web.context.request.async)
> doFilter:119, OncePerRequestFilter (org.springframework.web.filter)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:157, ChannelProcessingFilter
> (org.springframework.security.web.access.channel)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:87, MetadataGeneratorFilter
> (org.springframework.security.saml.metadata)
> doFilter:334, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilterInternal:215, FilterChainProxy (org.springframework.security.web)
> doFilter:178, FilterChainProxy (org.springframework.security.web)
> invokeDelegate:358, DelegatingFilterProxy (o
Re: Tomcat 9.0.37 Clustered DeltaManager Duplicates Session And Loses Session Attributes
d:788, SimpleTcpCluster (org.apache.catalina.ha.tcp)
messageReceived:771, SimpleTcpCluster (org.apache.catalina.ha.tcp)
messageReceived:335, GroupChannel (org.apache.catalina.tribes.group)
messageReceived:91, ChannelInterceptorBase (org.apache.catalina.tribes.group)
messageReceived:97, StaticMembershipInterceptor
(org.apache.catalina.tribes.group.interceptors)
messageReceived:91, ChannelInterceptorBase (org.apache.catalina.tribes.group)
messageReceived:175, TcpPingInterceptor
(org.apache.catalina.tribes.group.interceptors)
messageReceived:91, ChannelInterceptorBase (org.apache.catalina.tribes.group)
messageReceived:117, TcpFailureDetector
(org.apache.catalina.tribes.group.interceptors)
messageReceived:91, ChannelInterceptorBase (org.apache.catalina.tribes.group)
messageReceived:91, ChannelInterceptorBase (org.apache.catalina.tribes.group)
messageReceived:274, ChannelCoordinator (org.apache.catalina.tribes.group)
messageDataReceived:261, ReceiverBase (org.apache.catalina.tribes.transport)
drainChannel:216, NioReplicationTask (org.apache.catalina.tribes.transport.nio)
run:101, NioReplicationTask (org.apache.catalina.tribes.transport.nio)
runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
run:748, Thread (java.lang)
On Fri, Oct 9, 2020 at 11:40 AM Tim N wrote:
> > Can you show us how you configured this cluster please?
>
> Sure.
>
> Tomcat tomcat = new Tomcat();
> tomcat.setBaseDir(baseDir);
> tomcat.getServer().setAddress("127.0.0.1");
> tomcat.getServer().setPort(shutDownPort);
>
> tomcat.getServer().setShutdown("SHUTDOWN");
> tomcat.getServer().addLifecycleListener(new AprLifecycleListener());
> tomcat.getServer().addLifecycleListener(new
> JreMemoryLeakPreventionListener());
> tomcat.getServer().addLifecycleListener(new
> GlobalResourcesLifecycleListener());
> tomcat.getServer().addLifecycleListener(new
> ThreadLocalLeakPreventionListener());
>
> tomcat.setPort(httpPort);
> tomcat.getConnector().getPort();//The default connector will only be created
> if getConnector is called
>
> LaunchServerHelper.addRemoteIpValve(tomcat);
>
> //...
>
> StandardHost hostManage = getStandardHost(tomcat, "manage." + sgDomain,
> "sg-manage", serverProperties);
> tomcat.getEngine().addChild(hostManage);
>
> tomcat.start();
> tomcat.getServer().await();
> tomcat.stop();
>
>
> private static StandardHost getStandardHost(Tomcat tomcat, String name,
> String module, Properties serverProperties) {
> StandardHost host = new StandardHost();
>
> modifyHost(tomcat, name, module, host, serverProperties);
> return host;
> }
>
>
> private static void modifyHost(Tomcat tomcat, String name, String module,
> StandardHost host, Properties serverProperties) {
> String webappDirLocation = module + "/src/main/webapp/";
> File webAppDir = new File(webappDirLocation);
>
> host.setName(name);
> String[] aliases = serverProperties.getProperty("tomcat-" + module +
> "-aliases", "").split(",");
> for (String alias : aliases) {
> if (alias.length() > 0) {
> logger.log(Level.INFO, "Adding alias {0} for {1}", new Object[] {alias,
> module});
> host.addAlias(alias);
> }
> }
> host.setParent(tomcat.getEngine());
> host.setAppBase(webAppDir.getAbsolutePath());
>
> StandardContext ctx = (StandardContext) tomcat.addWebapp(host, "/",
> webAppDir.getAbsolutePath());
> ((StandardJarScanner) ctx.getJarScanner()).setScanManifest(false);
> ctx.setCookieProcessor(new LegacyCookieProcessor());
>
> // Declare an alternative location for your "WEB-INF/classes" dir
> // Servlet 3.0 annotation will work
> File additionWebInfClasses = new File(module + "/target/classes");
> WebResourceRoot resources = new StandardRoot(ctx);
> resources.addPreResources(new DirResourceSet(resources, "/WEB-INF/classes",
> additionWebInfClasses.getAbsolutePath(), "/"));
> ctx.setResources(resources);
>
> LaunchServerHelper.addSimpleTcpCluster(host, 4000, serverProperties);
> }
>
>
> public static void addSimpleTcpCluster(StandardHost host, int port,
> Properties serverProperties) {
> if (!serverProperties.containsKey("tomcat-clusterMemberCount")) {
> return;
> }
>
> SimpleTcpCluster cluster = new SimpleTcpCluster();
> cluster.setClusterName("SG-cluster");
> cluster.setChannelStartOptions(3);
> cluster.setChannelSendOptions(8);
>
> {
> DeltaManager clusterManager = new DeltaManager();
> clusterManager.setName("SG-cluster-manager");
> clusterManager.setExpi
Re: Tomcat 9.0.37 Clustered DeltaManager Duplicates Session And Loses Session Attributes
uot;
+ i));
interceptor.addStaticMember(member);
}
channel.addInterceptor(interceptor);
}
channel.addInterceptor(new TcpPingInterceptor());
channel.addInterceptor(new TcpFailureDetector());
channel.addInterceptor(new MessageDispatchInterceptor());
}
ReplicationTransmitter replicationTransmitter = new ReplicationTransmitter();
PooledParallelSender sender = new PooledParallelSender();
sender.setTimeout(6);
sender.setMaxRetryAttempts(5);
replicationTransmitter.setTransport(sender);
ReplicationValve replicationValve = new ReplicationValve();
replicationValve.setFilter("");
cluster.addValve(replicationValve);
cluster.addValve(new JvmRouteBinderValve());
FarmWarDeployer farmDeployer = new FarmWarDeployer();
farmDeployer.setTempDir("/tmp/war-temp/");
farmDeployer.setDeployDir("/tmp/war-deploy/");
farmDeployer.setWatchDir("/tmp/war-listen/");
farmDeployer.setWatchEnabled(false);
cluster.setClusterDeployer(farmDeployer);
//cluster.addClusterListener(new
JvmRouteSessionIDBinderListener());//Removed in Tomcat 8.
https://tomcat.apache.org/migration-8.html#Clustering
cluster.addClusterListener(new ClusterSessionListener());
host.setCluster(cluster);
}
tomcat-clusterAddress=192.168.0.2
tomcat-clusterMemberUniqueId={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}
tomcat-clusterMemberCount=1
tomcat-clusterMemberAddress1=192.168.0.3
tomcat-clusterMemberUniqueId1={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2}
This was initially converted from a server.xml configuration a year ago on
Tomcat 7 with minor modifications as we've upgraded to Tomcat 8 then 9.
Cheers,
Tim
On Thu, Oct 8, 2020 at 10:17 PM Mark Thomas wrote:
> On 08/10/2020 10:04, Tim N wrote:
> > Hi,
> >
> > I'm in the early stages of analysing this problem:
> >
> >- Tomcat Embedded 9.0.37 with clustering enabled
> >- SpringBoot application, 2.1.16
> >- Login with no existing JSESSIONID fails
> >
> > I can see the following code is executed twice within one request, the
> > login attempt:
> >
> >
> *~/.m2/repository/org/apache/tomcat/tomcat-catalina/9.0.37/tomcat-catalina-9.0.37-sources.jar!/org/apache/catalina/session/ManagerBase.java:677*
> >
> > public void add(Session session) {
> > sessions.put(session.getIdInternal(), session);
> >
> > The first time it's executed, the session with the Spring context is
> added.
> > The second time it's executed, a second session with the same ID, but
> > without the Spring context, or any other session attribute I add for that
> > matter, overwrites the existing session, and login fails. If I debug and
> > prevent this by renaming the second session ID, login works because the
> > original session is preserved.
> >
> > The stack-trace for the first call is shown below:
> >
> > add:678, ManagerBase (org.apache.catalina.session)
> > setId:358, StandardSession (org.apache.catalina.session)
> > setId:327, DeltaSession (org.apache.catalina.ha.session)
> > setId:345, DeltaSession (org.apache.catalina.ha.session)
> > createSession:719, ManagerBase (org.apache.catalina.session)
> > createSession:422, DeltaManager (org.apache.catalina.ha.session)
> > createSession:410, DeltaManager (org.apache.catalina.ha.session)
> > doGetSession:3043, Request (org.apache.catalina.connector)
> > getSession:2441, Request (org.apache.catalina.connector)
>
>
>
> This is the app triggering the creation of the session.
>
> > The stack-trace for the second call is shown below:
> >
> > add:678, ManagerBase (org.apache.catalina.session)
> > setId:358, StandardSession (org.apache.catalina.session)
> > setId:327, DeltaSession (org.apache.catalina.ha.session)
> > handleSESSION_CREATED:1322, DeltaManager (org.apache.catalina.ha.session)
> > messageReceived:1192, DeltaManager (org.apache.catalina.ha.session)
>
>
>
> This is the DeltaManager receiving notification that a new session has
> been created.
>
> > Any help would be appreciated. I can replicate this every time and spend
> > some time investigating this.
>
> The new session created message should be send to (and then processed
> on) every node *except* the node on which the session was originally
> created.
>
> Can you show us how you configured this cluster please?
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Tomcat 9.0.37 Clustered DeltaManager Duplicates Session And Loses Session Attributes
Hi,
I'm in the early stages of analysing this problem:
- Tomcat Embedded 9.0.37 with clustering enabled
- SpringBoot application, 2.1.16
- Login with no existing JSESSIONID fails
I can see the following code is executed twice within one request, the
login attempt:
*~/.m2/repository/org/apache/tomcat/tomcat-catalina/9.0.37/tomcat-catalina-9.0.37-sources.jar!/org/apache/catalina/session/ManagerBase.java:677*
public void add(Session session) {
sessions.put(session.getIdInternal(), session);
The first time it's executed, the session with the Spring context is added.
The second time it's executed, a second session with the same ID, but
without the Spring context, or any other session attribute I add for that
matter, overwrites the existing session, and login fails. If I debug and
prevent this by renaming the second session ID, login works because the
original session is preserved.
The stack-trace for the first call is shown below:
add:678, ManagerBase (org.apache.catalina.session)
setId:358, StandardSession (org.apache.catalina.session)
setId:327, DeltaSession (org.apache.catalina.ha.session)
setId:345, DeltaSession (org.apache.catalina.ha.session)
createSession:719, ManagerBase (org.apache.catalina.session)
createSession:422, DeltaManager (org.apache.catalina.ha.session)
createSession:410, DeltaManager (org.apache.catalina.ha.session)
doGetSession:3043, Request (org.apache.catalina.connector)
getSession:2441, Request (org.apache.catalina.connector)
getSession:908, RequestFacade (org.apache.catalina.connector)
getSession:920, RequestFacade (org.apache.catalina.connector)
getSession:253, HttpServletRequestWrapper (javax.servlet.http)
getSession:253, HttpServletRequestWrapper (javax.servlet.http)
getSession:253, HttpServletRequestWrapper (javax.servlet.http)
onAuthentication:66, RegisterSessionAuthenticationStrategy
(org.springframework.security.web.authentication.session)
doFilter:218, AbstractAuthenticationProcessingFilter
(org.springframework.security.web.authentication)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:200, AbstractAuthenticationProcessingFilter
(org.springframework.security.web.authentication)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:116, LogoutFilter
(org.springframework.security.web.authentication.logout)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilterInternal:74, HeaderWriterFilter
(org.springframework.security.web.header)
doFilter:119, OncePerRequestFilter (org.springframework.web.filter)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:74, CSRFSameOriginHeaderCheckFilter (ourcompany.common.web)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:36, SessionTrackingFilter (ourcompany.common.web)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:105, SecurityContextPersistenceFilter
(org.springframework.security.web.context)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilterInternal:56, WebAsyncManagerIntegrationFilter
(org.springframework.security.web.context.request.async)
doFilter:119, OncePerRequestFilter (org.springframework.web.filter)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:157, ChannelProcessingFilter
(org.springframework.security.web.access.channel)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilter:87, MetadataGeneratorFilter
(org.springframework.security.saml.metadata)
doFilter:334, FilterChainProxy$VirtualFilterChain
(org.springframework.security.web)
doFilterInternal:215, FilterChainProxy (org.springframework.security.web)
doFilter:178, FilterChainProxy (org.springframework.security.web)
invokeDelegate:358, DelegatingFilterProxy (org.springframework.web.filter)
doFilter:271, DelegatingFilterProxy (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
invoke:202, StandardWrapperValve (org.apache.catalina.core)
__invoke:96, StandardContextValve (org.apache.catalina.core)
invoke:41002, StandardContextValve (org.apache.catalina.core)
invoke:541, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:139, StandardHostValve (org.apache.catalina.core)
invoke:182, JvmRouteBinderValve (org.apache.catalina.ha.session)
invoke:330, ReplicationValve (org.apache.catalina.ha.tcp)
invoke:92, ErrorReportValve (org.apache.catalina.valves)
invoke:74, StandardEngineValve (org.apache.catalina.core)
invoke:747, RemoteIpValve (org.apache.catalina.valves)
service:343, CoyoteAdapter (org.apache.catalina.connector)
service:373, Http11Processor (org.apache.coyote.http11)
process:65, AbstractProcessorLight (org.apache.coyote)
process:868, AbstractProt
