Re: Mixing Root Context webapp with other webapps
Jerry, On 7/9/21 01:58, Jerry Malcolm wrote: I have one webapp that processes REST-style url paths and therefore needs to run in the ROOT context. I'm not sure the conclusion follows from the premise, here. You can certainly use REST-style URL paths and not have a context at the top-level. Is it possible to run other webapps in the same host with other non-root contexts? It is, but I wouldn't recommend it. Well... I would definitely recommend /against/ it in some situations. Specifically, when both the root and other web applications both need to use cookie-based sessions. If you have two applications fighting over whose JSESSIONID cookie is the one to use for login, Bad Things can happen. If your root context and/or none of the non-root contexts will be using cookie-based session-tracking, then you will probably be fine. In other words, when resolving a URL to a web app, does it try to map the url to the defined context strings first, and then to ROOT if there are no matches? Or does ROOT override everything, and all URLs go to ROOT if it's defined? It's the latter, otherwise it would be pretty much impossible to deploy anything when a ROOT context was present. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thanks for your help, and all the help you provide to people on this list. Your replies are always quick, professional, and helpful. A big part of what makes Tomcat so great is the assistance that can be found on this list! Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Mark Thomas Sent: Friday, July 9, 2021 1:31 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak On 09/07/2021 18:23, Mark A. Claassen wrote: > Thank you so much! This is good to know. > > We may not change anything then (until that server gets upgraded). However, > would switching back to HTTP 1.1 reduce the memory footprint in the mean time? Yes. The issue is the HTTP/2 priority tree. Essentially, Tomcat has to keep some information around about the previous few hundred requests on every HTTP/2 connection. Until .37/.39 Tomcat just kept objects used for the request/response. As of .37/.39 Tomcat replaces these with a much lighter object once the request is completed. > Would the connection be cleaned up when the browser goes away? Should be. Mark > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > -Original Message- > From: Mark Thomas > Sent: Friday, July 9, 2021 12:59 PM > To: users@tomcat.apache.org > Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak > Importance: Low > > On 09/07/2021 16:21, Mark A. Claassen wrote: >> Thanks. I have done more heap analysis and think I have it tracked closer >> to the source. >> >> -- >> I started looking at the heap a different way. The random values I looked >> at before (of the 80,000) may not have be as representative as I thought. >> >> Examining the retained sizes in the heap, I am finding: >> I have two instances of AbstractProtocol$ConnectionHandler. >> >> One of these AbstractProtocol$ConnectionHandler instances has a >> ConcurrentHashMap called "connections" >> This map as 32 elements in its "table". Most of these are null. Some of >> the ones that are not, are huge. >> The entirety of the map retains 112MG. >> >> Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. >> Looking at the "val" variable of a node, there is an >> UpgradeProcessorInternal Inside this is a variable called >> internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I >> am looking at now retains 16MG of memory. >> (Oddly, once I get this far, the retained sizes of its internal >> objects don't really add up.) >> >> Any ideas on how to work around this? Or if this is already fixed in a >> later version of Tomcat? > > That isn't a leak. That is high memory usage. The objects will be GC'd once > the HTTP/2 connection closes. > > The changes in 9.0.37 / 9.0.39 should reduce the memory footprint > considerably. > > Mark > > >> >> Thanks, >> >> Mark Claassen >> Senior Software Engineer >> >> Donnell Systems, Inc. >> 130 South Main Street >> Leighton Plaza Suite 375 >> South Bend, IN 46601 >> E-mail: mailto:mclaas...@ocie.net >> Voice: (574)232-3784 >> Fax: (574)232-4014 >> >> Disclaimer: >> The opinions provided herein do not necessarily state or reflect >> those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and >> assumes no legal liability or responsibility for the posting. >> >> >> >> >> -Original Message- >> From: Rob Sargent >> Sent: Thursday, July 8, 2021 6:50 PM >> To: users@tomcat.apache.org >> Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak >> Importance: Low >> >> >> >> On 7/8/21 3:17 PM, Mark A. Claassen wrote: >>> Ok. That didn’t seem to work. I will investigate further and try to find >>> a way to send that information. >>> >>> It is not that busy a server, but the memory use increase
Re: [Possible Spam] Re: HTTP/2 Memory Leak
On 09/07/2021 18:23, Mark A. Claassen wrote: Thank you so much! This is good to know. We may not change anything then (until that server gets upgraded). However, would switching back to HTTP 1.1 reduce the memory footprint in the mean time? Yes. The issue is the HTTP/2 priority tree. Essentially, Tomcat has to keep some information around about the previous few hundred requests on every HTTP/2 connection. Until .37/.39 Tomcat just kept objects used for the request/response. As of .37/.39 Tomcat replaces these with a much lighter object once the request is completed. Would the connection be cleaned up when the browser goes away? Should be. Mark Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Friday, July 9, 2021 12:59 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 09/07/2021 16:21, Mark A. Claassen wrote: Thanks. I have done more heap analysis and think I have it tracked closer to the source. -- I started looking at the heap a different way. The random values I looked at before (of the 80,000) may not have be as representative as I thought. Examining the retained sizes in the heap, I am finding: I have two instances of AbstractProtocol$ConnectionHandler. One of these AbstractProtocol$ConnectionHandler instances has a ConcurrentHashMap called "connections" This map as 32 elements in its "table". Most of these are null. Some of the ones that are not, are huge. The entirety of the map retains 112MG. Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. Looking at the "val" variable of a node, there is an UpgradeProcessorInternal Inside this is a variable called internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I am looking at now retains 16MG of memory. (Oddly, once I get this far, the retained sizes of its internal objects don't really add up.) Any ideas on how to work around this? Or if this is already fixed in a later version of Tomcat? That isn't a leak. That is high memory usage. The objects will be GC'd once the HTTP/2 connection closes. The changes in 9.0.37 / 9.0.39 should reduce the memory footprint considerably. Mark Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Rob Sargent Sent: Thursday, July 8, 2021 6:50 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 7/8/21 3:17 PM, Mark A. Claassen wrote: Ok. That didn’t seem to work. I will investigate further and try to find a way to send that information. It is not that busy a server, but the memory use increases very quickly. Doing a class_histogram shows MessageBytes growing by the thousands every 30 minutes. (We have a temporary monitor script in place that does a GC and then prints a class_histogram every half hour to help us pinpoint what is happening.) Thanks, Mark Perhaps you've done this already, but grep -R 'static HashMap' src might locate some potential culprits. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thank you so much! This is good to know. We may not change anything then (until that server gets upgraded). However, would switching back to HTTP 1.1 reduce the memory footprint in the mean time? Would the connection be cleaned up when the browser goes away? Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Friday, July 9, 2021 12:59 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 09/07/2021 16:21, Mark A. Claassen wrote: > Thanks. I have done more heap analysis and think I have it tracked closer to > the source. > > -- > I started looking at the heap a different way. The random values I looked at > before (of the 80,000) may not have be as representative as I thought. > > Examining the retained sizes in the heap, I am finding: > I have two instances of AbstractProtocol$ConnectionHandler. > > One of these AbstractProtocol$ConnectionHandler instances has a > ConcurrentHashMap called "connections" > This map as 32 elements in its "table". Most of these are null. Some of the > ones that are not, are huge. > The entirety of the map retains 112MG. > > Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. > Looking at the "val" variable of a node, there is an > UpgradeProcessorInternal Inside this is a variable called > internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I > am looking at now retains 16MG of memory. > (Oddly, once I get this far, the retained sizes of its internal > objects don't really add up.) > > Any ideas on how to work around this? Or if this is already fixed in a later > version of Tomcat? That isn't a leak. That is high memory usage. The objects will be GC'd once the HTTP/2 connection closes. The changes in 9.0.37 / 9.0.39 should reduce the memory footprint considerably. Mark > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > > > > > -Original Message- > From: Rob Sargent > Sent: Thursday, July 8, 2021 6:50 PM > To: users@tomcat.apache.org > Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak > Importance: Low > > > > On 7/8/21 3:17 PM, Mark A. Claassen wrote: >> Ok. That didn’t seem to work. I will investigate further and try to find a >> way to send that information. >> >> It is not that busy a server, but the memory use increases very quickly. >> Doing a class_histogram shows MessageBytes growing by the thousands every 30 >> minutes. >> >> (We have a temporary monitor script in place that does a GC and then >> prints a class_histogram every half hour to help us pinpoint what is >> happening.) >> >> Thanks, >> Mark >> > Perhaps you've done this already, but > > grep -R 'static HashMap' src > > might locate some potential culprits. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mixing Root Context webapp with other webapps
On 7/9/2021 2:23 AM, Olaf Kock wrote: On 09.07.21 07:58, Jerry Malcolm wrote: I have one webapp that processes REST-style url paths and therefore needs to run in the ROOT context. Is it possible to run other webapps in the same host with other non-root contexts? In other words, when resolving a URL to a web app, does it try to map the url to the defined context strings first, and then to ROOT if there are no matches? Or does ROOT override everything, and all URLs go to ROOT if it's defined? If memory serves me well and this behavior didn't change in the past decade, then all other web applications have precedence over root. That is, if you deploy ROOT.war and json.war (and assume the context-path to be /json), then your root application's /json path would never be reached. It's easy to visualize this way around, because it's an absolutely static mapping with the size being "number of webapps", while the other way around, ROOT could also map /* to one of its servlets and then determine what to do it. The spec has to means to explicitly hand a request back to the appserver and every app would rather generate 404 than check if somebody else might be there to handle it. Olaf Thanks for the quick response, Olaf. That's the way I was hoping it worked... :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Possible Spam] Re: HTTP/2 Memory Leak
On 09/07/2021 16:21, Mark A. Claassen wrote: Thanks. I have done more heap analysis and think I have it tracked closer to the source. -- I started looking at the heap a different way. The random values I looked at before (of the 80,000) may not have be as representative as I thought. Examining the retained sizes in the heap, I am finding: I have two instances of AbstractProtocol$ConnectionHandler. One of these AbstractProtocol$ConnectionHandler instances has a ConcurrentHashMap called "connections" This map as 32 elements in its "table". Most of these are null. Some of the ones that are not, are huge. The entirety of the map retains 112MG. Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. Looking at the "val" variable of a node, there is an UpgradeProcessorInternal Inside this is a variable called internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I am looking at now retains 16MG of memory. (Oddly, once I get this far, the retained sizes of its internal objects don't really add up.) Any ideas on how to work around this? Or if this is already fixed in a later version of Tomcat? That isn't a leak. That is high memory usage. The objects will be GC'd once the HTTP/2 connection closes. The changes in 9.0.37 / 9.0.39 should reduce the memory footprint considerably. Mark Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Rob Sargent Sent: Thursday, July 8, 2021 6:50 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 7/8/21 3:17 PM, Mark A. Claassen wrote: Ok. That didn’t seem to work. I will investigate further and try to find a way to send that information. It is not that busy a server, but the memory use increases very quickly. Doing a class_histogram shows MessageBytes growing by the thousands every 30 minutes. (We have a temporary monitor script in place that does a GC and then prints a class_histogram every half hour to help us pinpoint what is happening.) Thanks, Mark Perhaps you've done this already, but grep -R 'static HashMap' src might locate some potential culprits. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 10.0 as Tomcat reverse proxy does not send auth_type and remote_user AJP heder
On 09/07/2021 16:59, Paolo Clerici wrote: I use IIS 10.0 as a reverse proxy of Tomcat 7. IIS 10.0 use Windows Authentication. When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get the null value. When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I get the null value. Using IIS 6.1 with the same version of Tomcat everything works fine. When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get "NTLM" string. When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I get the name of the user who authenticated with IIS. The configuration of the two versions of IIS appears to be the same. Clearly it isn't the same since when I tested this with IIS 10.0 it worked exactly as expected. Seems to be missing some AJP headers including: remote_user (0x03) and auth_type (0x04) which instead are sent from IIS 6.1. Below isapi connector debug log (auth and user are null): Fri Jul 09 17:00:52.743 2021] [4608:4712] [debug] init_ws_service::jk_isapi_plugin.c (3295): Service protocol=HTTP/1.1 method=GET host=10.10.12.102 addr=10.10.12.102 name=qa-b2b.dasitgroup.it port=443 auth=(null) user=(null) uri=/s2wweb/faces/login.xhtml That points to an IIS configuration issue. How did you configure authentication? Mark Product: Tomcat Connectors Component: isapi Version: 1.2.48 Windows version: Windows Server 2016 IIS Version: 10.0 Tomcat version: 7 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
IIS 10.0 as Tomcat reverse proxy does not send auth_type and remote_user AJP heder
I use IIS 10.0 as a reverse proxy of Tomcat 7. IIS 10.0 use Windows Authentication. When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get the null value. When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I get the null value. Using IIS 6.1 with the same version of Tomcat everything works fine. When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get "NTLM" string. When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I get the name of the user who authenticated with IIS. The configuration of the two versions of IIS appears to be the same. Seems to be missing some AJP headers including: remote_user (0x03) and auth_type (0x04) which instead are sent from IIS 6.1. Below isapi connector debug log (auth and user are null): Fri Jul 09 17:00:52.743 2021] [4608:4712] [debug] init_ws_service::jk_isapi_plugin.c (3295): Service protocol=HTTP/1.1 method=GET host=10.10.12.102 addr=10.10.12.102 name=qa-b2b.dasitgroup.it port=443 auth=(null) user=(null) uri=/s2wweb/faces/login.xhtml Product: Tomcat Connectors Component: isapi Version: 1.2.48 Windows version: Windows Server 2016 IIS Version: 10.0 Tomcat version: 7 Thank you, Paolo Clerici - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thanks. I have done more heap analysis and think I have it tracked closer to the source. -- I started looking at the heap a different way. The random values I looked at before (of the 80,000) may not have be as representative as I thought. Examining the retained sizes in the heap, I am finding: I have two instances of AbstractProtocol$ConnectionHandler. One of these AbstractProtocol$ConnectionHandler instances has a ConcurrentHashMap called "connections" This map as 32 elements in its "table". Most of these are null. Some of the ones that are not, are huge. The entirety of the map retains 112MG. Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. Looking at the "val" variable of a node, there is an UpgradeProcessorInternal Inside this is a variable called internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I am looking at now retains 16MG of memory. (Oddly, once I get this far, the retained sizes of its internal objects don't really add up.) Any ideas on how to work around this? Or if this is already fixed in a later version of Tomcat? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Rob Sargent Sent: Thursday, July 8, 2021 6:50 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 7/8/21 3:17 PM, Mark A. Claassen wrote: > Ok. That didn’t seem to work. I will investigate further and try to find a > way to send that information. > > It is not that busy a server, but the memory use increases very quickly. > Doing a class_histogram shows MessageBytes growing by the thousands every 30 > minutes. > > (We have a temporary monitor script in place that does a GC and then prints a > class_histogram every half hour to help us pinpoint what is happening.) > > Thanks, > Mark > Perhaps you've done this already, but grep -R 'static HashMap' src might locate some potential culprits.
Re: Tomcat Jasper Compiler ant task not working - missing tag lib validator
On 08/07/2021 23:12, Builder Lynx Demo wrote:
Hi Chris, Mark,
Thank you for pointing that out. I never would have guessed that.
Updating the separator addresses that issue. However now the jasper
task throws an exception:
BUILD FAILED
/home/alex/cc/build.xml:534: The following error occurred while
executing this line:
/home/alex/cc/build.xml:397: The following error occurred while
executing this line:
/home/alex/cc/build.xml:430: The following error occurred while
executing this line:
/home/alex/cc/build.xml:457: The following error occurred while
executing this line:
/home/alex/cc/build.xml:511: java.lang.NoClassDefFoundError:
javax/servlet/jsp/tagext/TagLibraryValidator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
The class "javax/servlet/jsp/tagext/TagLibraryValidator" is in the file
{$TOMCAT_HOME}/lib/jsp-api.jar
I have verified that the jar is in the ant's
value. For reference the full classpath variable is below.
It seems the not found class is not the "TagLibraryValidator" (I'm
pretty sure that is on the classpath). Maybe it is some other class
that "TagLibraryValidator" references? Any idea how to determine
exactly which class can not be found?
I suspect multiple instances of the same class. I don't see anything
obvious in the class path that was cause that but I do see instances of
what looks like duplicate JARs. For example: ecj.jar and jdt-compilier.jar
Mark
Thanks
Alex.
[echo] classpath:
lib/activation.jar:/usr/java/ant/lib/ant.jar:lib/antlr.jar:lib/avalon-framework-4.1.4.jar:lib/axiom-api.jar:lib/axiom-dom.jar:lib/axiom-impl.jar:lib/axis2-adb-codegen.jar:lib/axis2-adb.jar:lib/axis2-corba.jar:lib/axis2-fastinfoset.jar:lib/axis2-java2wsdl.jar:lib/axis2-jaxbri.jar:lib/axis2-jaxws.jar:lib/axis2-json.jar:lib/axis2-kernel.jar:lib/axis2-metadata.jar:lib/axis2-mtompolicy.jar:lib/axis2-saaj.jar:lib/axis2-spring.jar:lib/axis2-transport-http.jar:lib/axis2-transport-local.jar:lib/axis2-xmlbeans.jar:lib/bcel.jar:lib/bsh.jar:/usr/java/tomcat/lib/catalina.jar:cc/WEB-INF/classes/:lib/c-jdbc-driver.jar:lib/commons-lang3.jar:lib/commons-beanutils-core.jar:lib/commons-beanutils.jar:lib/commons-beanutils-bean-collections.jar:lib/commons-codec.jar:lib/commons-collections.jar:lib/commons-compiler.jar:lib/commons-dbcp.jar:lib/commons-digester.jar:lib/commons-email.jar:lib/commons-fileupload.jar:lib/commons-httpclient.jar:lib/commons-io.jar:lib/commons-javaflow.jar:lib/commons-logging-api.jar:lib/commons-logging.jar:lib/commons-pool.jar:lib/consyntools.jar:corp/WEB-INF/classes/:lib/derby.jar:lib/derbytools.jar:lib/dnsjava.jar:lib/dom4j.jar:lib/fdsapi.jar:lib/fonts.jar:lib/gson.jar:lib/gnu-regexp-1.1.4.jar:lib/gnujaxp.jar:lib/groovy-all.jar:lib/hibernate3.jar:lib/homebuildingimages.jar:lib/hsqldb.jar:lib/httpclient.jar:lib/httpcore.jar:lib/jsoup.jar:lib/httpunit.jar:lib/ical4j.jar:lib/icu4j_2_6_1.jar:lib/itext.jar:lib/itext-pdfa.jar:lib/j2ssh-core-0.2.6.jar:lib/jakarta-bcel.jar:lib/jakarta-oro.jar:lib/jakarta-poi.jar:lib/jakarta-poi-ooxml.jar:lib/jakarta-poi-ooxml-schemas.jar:lib/jakarta-regexp-1.2.jar:lib/JAMon.jar:lib/janino.jar:{ecj}:/usr/java/tomcat/lib/el-api.jar:/usr/java/tomcat/lib/jasper.jar:/usr/java/tomcat/lib/jasper-el.jar:/usr/java/tomcat/lib/jaspic-api.jar:lib/jasperreports.jar:lib/jasperreports-fonts.jar:lib/jasperreports-javaflow.jar:lib/jaxb-api.jar:lib/jaxb-impl.jar:lib/jaxb-xjc.jar:lib/jaxen.jar:lib/jdom.jar:lib/jdt-compiler.jar:lib/jettison.jar:lib/jfreechart-common.jar:lib/jfreechart-demo.jar:lib/jfreechart.jar:lib/jibx-bind.jar:lib/jibx-run.jar:lib/jlfgr-1_0.jar:lib/jpa.jar:lib/jrobin.jar:lib/json.jar:lib/jspdoc20030306.jar:lib/junit.jar:lib/jxl.jar:lib/krysalis-barcode.jar:lib/log4j.jar:lib/mail.jar:lib/maxmindgeoip.jar:lib/mex-impl.jar:lib/mondrian.jar:lib/mpxj.jar:lib/mysql-connector-java-bin.jar:lib/pvjdbc2.jar:lib/neethi.jar:lib/packtag.jar:lib/PDFBox.jar:lib/PDFRenderer.jar:lib/png-encoder.jar:lib/proguard.jar:lib/QBXMLBeans.jar:lib/DynamicsSLXMLBeans.jar:lib/RmiJdbc.jar:lib/saaj-api.jar:/usr/java/tomcat/lib/servlet-api.jar:/usr/java/tomcat/lib/el-api.jar:/usr/java/tomcat/lib/jsp-api.jar:/usr/java/tomcat/lib/jasper.jar:/usr/java/tomcat/lib/tomcat-api.jar:lib/soapmonitor.jar:lib/tc.jar:lib/sqlite-jdbc.jar:lib/turbine-connpool.jar:lib/wsdl4j.jar:lib/xalan.jar:lib/xbean_xpath.jar:lib/xbean.jar:lib/xercesImpl.jar:lib/xml-apis.jar:lib/xml-resolver.jar:lib/xmlbeans.jar:lib/xmlParserAPIs.jar:lib/xmlpublic.jar:lib/XSS.jar:lib/TarionFormDataBeans.jar:lib/SigPlus.jar:lib/SigPlus.RXTXcomm.jar:lib/barbecue.jar:lib/batik-anim.jar:lib/batik-awt-util.jar:lib/batik-bridge.jar:lib/batik-css.jar:lib/batik-dom.jar:lib/batik-ext.jar:lib/batik-gvt.jar:lib/batik-parser.
Re: Mixing Root Context webapp with other webapps
On 09/07/2021 08:23, Olaf Kock wrote: On 09.07.21 07:58, Jerry Malcolm wrote: I have one webapp that processes REST-style url paths and therefore needs to run in the ROOT context. Is it possible to run other webapps in the same host with other non-root contexts? In other words, when resolving a URL to a web app, does it try to map the url to the defined context strings first, and then to ROOT if there are no matches? Or does ROOT override everything, and all URLs go to ROOT if it's defined? If memory serves me well and this behavior didn't change in the past decade, then all other web applications have precedence over root. That is, if you deploy ROOT.war and json.war (and assume the context-path to be /json), then your root application's /json path would never be reached. It's easy to visualize this way around, because it's an absolutely static mapping with the size being "number of webapps", while the other way around, ROOT could also map /* to one of its servlets and then determine what to do it. The spec has to means to explicitly hand a request back to the appserver and every app would rather generate 404 than check if somebody else might be there to handle it. To put it another way, when mapping a request to a web application Tomcat: - normalises the request URL - routes the request to the web application with the longest matching context path The exact wording is in section 12 of the Servlet specification. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mixing Root Context webapp with other webapps
On 09.07.21 07:58, Jerry Malcolm wrote: > I have one webapp that processes REST-style url paths and therefore > needs to run in the ROOT context. Is it possible to run other webapps > in the same host with other non-root contexts? In other words, when > resolving a URL to a web app, does it try to map the url to the > defined context strings first, and then to ROOT if there are no > matches? Or does ROOT override everything, and all URLs go to ROOT if > it's defined? > If memory serves me well and this behavior didn't change in the past decade, then all other web applications have precedence over root. That is, if you deploy ROOT.war and json.war (and assume the context-path to be /json), then your root application's /json path would never be reached. It's easy to visualize this way around, because it's an absolutely static mapping with the size being "number of webapps", while the other way around, ROOT could also map /* to one of its servlets and then determine what to do it. The spec has to means to explicitly hand a request back to the appserver and every app would rather generate 404 than check if somebody else might be there to handle it. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
