Re: Migrating from Tomcat 9.0.x to 10.1.x
Amit,
On 4/4/24 22:21, Amit Pande wrote:
I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1
(10.1.20).
https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have
migrated the applications (which use Spring libraries 5.x).
While testing the migrated apps( which use web socket), ran into:
org.springframework.web.util.NestedServletException: Handler dispatch failed;
nested exception is java.lang.NoSuchMethodError: 'void
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
jakarta.servlet.http.HttpServletResponse,
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java
* @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It
has been replaced by
* {@link #upgradeHttpToWebSocket(Object, Object,
ServerEndpointConfig, Map)}
*/
@Deprecated
public void doUpgrade(HttpServletRequest request, HttpServletResponse
response, ServerEndpointConfig sec,
Map pathParams) throws ServletException,
IOException {
UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
}
Is this an issue with the migration tool to appropriately replace the removed
methods?
Or the applications using web sockets with Tomcat 9.x are required to be
updated before moving to Tomcat 10.1, instead of using the migration tool as an
intermediate step to upgrade to Tomcat 10.1 without having to update the
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.
The Migration Tool doesn't rewrite your code, it only rewrites the class
names referenced by your class files. (Okay, it also re-writes strings
in your files which match those class names as well.) But it will not
change method calls. It is not a Deprecation Cleanup Tool.
You should change your Java EE-compatible application to use
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first,
then run the Migration Tool on your application.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Migrating from Tomcat 9.0.x to 10.1.x
Hello,
I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1
(10.1.20).
https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have
migrated the applications (which use Spring libraries 5.x).
While testing the migrated apps( which use web socket), ran into:
org.springframework.web.util.NestedServletException: Handler dispatch failed;
nested exception is java.lang.NoSuchMethodError: 'void
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
jakarta.servlet.http.HttpServletResponse,
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java
* @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It
has been replaced by
* {@link #upgradeHttpToWebSocket(Object, Object,
ServerEndpointConfig, Map)}
*/
@Deprecated
public void doUpgrade(HttpServletRequest request, HttpServletResponse
response, ServerEndpointConfig sec,
Map pathParams) throws ServletException,
IOException {
UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
}
Is this an issue with the migration tool to appropriately replace the removed
methods?
Or the applications using web sockets with Tomcat 9.x are required to be
updated before moving to Tomcat 10.1, instead of using the migration tool as an
intermediate step to upgrade to Tomcat 10.1 without having to update the
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.
Appreciate the guidance.
Thanks,
Amit
Re: org.apache.catalina.valves.RemoteAddrValve
Eric, On 4/4/24 13:43, Eric Fetzer wrote: Hi All, When I originally set up my tomcat instance, I added the following to allow manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: That worked wonderfully. Now I'm trying to add another IP range by changing it to: This is not working. I tried to use 2\.4\.6\.\d+ as well but that didn't work either. I've verified I can get to port 8080 from the IP locations. Any idea what I'm doing wrong or do you have a means to troubleshoot this? I'm glad you are reporting that the issue is elsewhere and not a problem with your use of RemoteAddrValve. But I'd like to point out that since these are regular expressions, your specific use of them can lead to unintended consequences. For example: 1.3.5.* This will allow anyone from 1.3.5.1 or 1.3.5.99 or 1.3.5.254. That's probably fine. But it will also allow anybody from 103.50.99.24 as well. That probably wasn't intended. Changing it to the properly-escaped 1\.3\.5 but also trailing \..* (note there are two periods there) really means 1.3.5.whatever. Using \d isn't strictly necessary but it does make it clear that you aren't expecting non-digits e.g. hostnames. As you mentioned elsewhere in this thread, you thought it was "tomcat language". When it comes to security controls, /please read the documentation/ because knowing that it is a regular expression and not a "tomcat language" can mean the difference between configuring a security control properly or improperly. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [External] org.apache.catalina.valves.RemoteAddrValve
LOL, I'm decent at regex Robert. I got the \d+ from what ships in the context.xml: 127\.\d+\.\d+\.\d+ It looks like an attempt at saying localhost can get in as long as the localhost IP starts with 127. I assumed it wasn't actually regex but some "tomcat language"... Thanks for the education! I'll jump back on here if things don't work on the other side of the firewall... On Thu, Apr 4, 2024 at 12:11 PM Robert Egan wrote: > You need to read up on "regular expressions" (or "regex"). > > In a regular expression, a lowercase "d" is a single decimal digit. A "+" > means one or more of them. A period means ANY character (which is why you > have to escape it when you mean "period"). A backward slash means to treat > the character immediately after it normally and not as a special character. > So "\d" would mean the literal letter "d". > > There's more rules, but they're well documented all over the internet, so I > won't elaborate. > > Robert Egan > > > On Thu, Apr 4, 2024 at 2:01 PM Eric Fetzer wrote: > > > Thanks for the quick response Robert! So I tried escaping the periods > and > > putting the \d+ for the * but it didn't work. Is the \d+ incorrect in > > substitution for *? > > > > On Thu, Apr 4, 2024 at 11:53 AM Robert Egan > > wrote: > > > > > It looks like you need to escape your periods, like you did for 127\. > > > etc... > > > 1\.3\.5 > > > Robert Egan > > > > > > On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer > > wrote: > > > > > > > Hi All, > > > > > > > > When I originally set up my tomcat instance, I added the following to > > > allow > > > > manager access under > /opt/tomcat/webapps/manager/META-INF/context.xml: > > > > > > > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> > > > > > > > > That worked wonderfully. Now I'm trying to add another IP range by > > > > changing it to: > > > > > > > > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" > > > /> > > > > > > > > This is not working. I tried to use 2\.4\.6\.\d+ as well but that > > didn't > > > > work either. I've verified I can get to port 8080 from the IP > > locations. > > > > Any idea what I'm doing wrong or do you have a means to troubleshoot > > > this? > > > > > > > > Thanks, > > > > Eric > > > > > > > > > >
Re: [External] org.apache.catalina.valves.RemoteAddrValve
Sorry folks (Robert), but upon further testing, it looks like port 8080 isn't open on these IP's. I was mistaking the attempt to connect from my curl command with a response. I withdrawal my question for now. I'll reply to this thread if it doesn't work once the hole in the firewall is carved properly. Thanks! On Thu, Apr 4, 2024 at 11:58 AM Eric Fetzer wrote: > Thanks for the quick response Robert! So I tried escaping the periods and > putting the \d+ for the * but it didn't work. Is the \d+ incorrect in > substitution for *? > > On Thu, Apr 4, 2024 at 11:53 AM Robert Egan > wrote: > >> It looks like you need to escape your periods, like you did for 127\. >> etc... >> 1\.3\.5 >> Robert Egan >> >> On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer wrote: >> >> > Hi All, >> > >> > When I originally set up my tomcat instance, I added the following to >> allow >> > manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: >> > >> > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> >> > >> > That worked wonderfully. Now I'm trying to add another IP range by >> > changing it to: >> > >> > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" >> /> >> > >> > This is not working. I tried to use 2\.4\.6\.\d+ as well but that >> didn't >> > work either. I've verified I can get to port 8080 from the IP >> locations. >> > Any idea what I'm doing wrong or do you have a means to troubleshoot >> this? >> > >> > Thanks, >> > Eric >> > >> >
Re: [External] org.apache.catalina.valves.RemoteAddrValve
You need to read up on "regular expressions" (or "regex"). In a regular expression, a lowercase "d" is a single decimal digit. A "+" means one or more of them. A period means ANY character (which is why you have to escape it when you mean "period"). A backward slash means to treat the character immediately after it normally and not as a special character. So "\d" would mean the literal letter "d". There's more rules, but they're well documented all over the internet, so I won't elaborate. Robert Egan On Thu, Apr 4, 2024 at 2:01 PM Eric Fetzer wrote: > Thanks for the quick response Robert! So I tried escaping the periods and > putting the \d+ for the * but it didn't work. Is the \d+ incorrect in > substitution for *? > > On Thu, Apr 4, 2024 at 11:53 AM Robert Egan > wrote: > > > It looks like you need to escape your periods, like you did for 127\. > > etc... > > 1\.3\.5 > > Robert Egan > > > > On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer > wrote: > > > > > Hi All, > > > > > > When I originally set up my tomcat instance, I added the following to > > allow > > > manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: > > > > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> > > > > > > That worked wonderfully. Now I'm trying to add another IP range by > > > changing it to: > > > > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" > > /> > > > > > > This is not working. I tried to use 2\.4\.6\.\d+ as well but that > didn't > > > work either. I've verified I can get to port 8080 from the IP > locations. > > > Any idea what I'm doing wrong or do you have a means to troubleshoot > > this? > > > > > > Thanks, > > > Eric > > > > > >
Re: [External] org.apache.catalina.valves.RemoteAddrValve
Thanks for the quick response Robert! So I tried escaping the periods and putting the \d+ for the * but it didn't work. Is the \d+ incorrect in substitution for *? On Thu, Apr 4, 2024 at 11:53 AM Robert Egan wrote: > It looks like you need to escape your periods, like you did for 127\. > etc... > 1\.3\.5 > Robert Egan > > On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer wrote: > > > Hi All, > > > > When I originally set up my tomcat instance, I added the following to > allow > > manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> > > > > That worked wonderfully. Now I'm trying to add another IP range by > > changing it to: > > > > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" > /> > > > > This is not working. I tried to use 2\.4\.6\.\d+ as well but that didn't > > work either. I've verified I can get to port 8080 from the IP locations. > > Any idea what I'm doing wrong or do you have a means to troubleshoot > this? > > > > Thanks, > > Eric > > >
Re: [External] org.apache.catalina.valves.RemoteAddrValve
It looks like you need to escape your periods, like you did for 127\. etc... 1\.3\.5 Robert Egan On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer wrote: > Hi All, > > When I originally set up my tomcat instance, I added the following to allow > manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> > > That worked wonderfully. Now I'm trying to add another IP range by > changing it to: > > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" /> > > This is not working. I tried to use 2\.4\.6\.\d+ as well but that didn't > work either. I've verified I can get to port 8080 from the IP locations. > Any idea what I'm doing wrong or do you have a means to troubleshoot this? > > Thanks, > Eric >
org.apache.catalina.valves.RemoteAddrValve
Hi All, When I originally set up my tomcat instance, I added the following to allow manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: That worked wonderfully. Now I'm trying to add another IP range by changing it to: This is not working. I tried to use 2\.4\.6\.\d+ as well but that didn't work either. I've verified I can get to port 8080 from the IP locations. Any idea what I'm doing wrong or do you have a means to troubleshoot this? Thanks, Eric
Re: PKCS#8 encryption algorithm unrecognized
Java is 1.8.0_391 On Thu, Apr 4, 2024 at 1:35 PM Timothy Resh wrote: > I got the Object ID and version straight out of the Certificate using > Keystore Explorer. I'm not sure why there is a difference. > > The "\" is because I manually deleted the beginning part of the path. > It's correct in the actual file. > > Java is 1.8. > > On Wed, Apr 3, 2024 at 6:11 PM Konstantin Kolinko > wrote: > >> > Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption >> > algorithm with DER encoded OID of [2a864886f70d010c0103] was not >> recognised >> >> If I google for the above hex number, it finds the following: >> >> '2A864886F70D010C0103' -- 1.2.840.113549.1.12.1.3 >> pbeWithSHAAnd3-KeyTripleDES-CBC (PKCS #12 PbeIds) >> >> (actually a comment in some random source file, but it explains what >> the value is). >> >> If I manually decode that value, thanks to >> https://stackoverflow.com/a/24720842 >> I get the same value: >> >> 2a = 42 = 1 * 40 + 2 -> "1.2" >> 8648 = (0x06 * 128) + 0x48 = 6 * 128 + 72 = 840 >> 86f70d = ((0x06 * 128) + (0x77 * 128) + 0x0d = ((6 * 128) + 119) * 128 >> + 13 = 113549 >> 01 = 1 >> 0c = 12 >> 01 = 1 >> 03 = 3 >> >> I saw that you mentioned >> > The ASN.1 is OBJECT IDENTIFIER=Sha256WithRSAEncryption >> (1.2.840.113549.1.1.11) >> >> but the value is different. >> *.1.1.11 vs *.1.12.1.3 >> >> Maybe it helps. >> >> What is your version of Java? >> >> Isn't the algorithm (mentioned in the error message) deprecated, >> because it uses SHA-1 ? >> >> > SSLCertificateChainFile="C:Certificate\Public Key\WSD-2DNX4M3...cer" >> >> A '\' is missing after ':'. >> >> Best regards, >> Konstantin Kolinko >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: PKCS#8 encryption algorithm unrecognized
I got the Object ID and version straight out of the Certificate using Keystore Explorer. I'm not sure why there is a difference. The "\" is because I manually deleted the beginning part of the path. It's correct in the actual file. Java is 1.8. On Wed, Apr 3, 2024 at 6:11 PM Konstantin Kolinko wrote: > > Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption > > algorithm with DER encoded OID of [2a864886f70d010c0103] was not > recognised > > If I google for the above hex number, it finds the following: > > '2A864886F70D010C0103' -- 1.2.840.113549.1.12.1.3 > pbeWithSHAAnd3-KeyTripleDES-CBC (PKCS #12 PbeIds) > > (actually a comment in some random source file, but it explains what > the value is). > > If I manually decode that value, thanks to > https://stackoverflow.com/a/24720842 > I get the same value: > > 2a = 42 = 1 * 40 + 2 -> "1.2" > 8648 = (0x06 * 128) + 0x48 = 6 * 128 + 72 = 840 > 86f70d = ((0x06 * 128) + (0x77 * 128) + 0x0d = ((6 * 128) + 119) * 128 > + 13 = 113549 > 01 = 1 > 0c = 12 > 01 = 1 > 03 = 3 > > I saw that you mentioned > > The ASN.1 is OBJECT IDENTIFIER=Sha256WithRSAEncryption > (1.2.840.113549.1.1.11) > > but the value is different. > *.1.1.11 vs *.1.12.1.3 > > Maybe it helps. > > What is your version of Java? > > Isn't the algorithm (mentioned in the error message) deprecated, > because it uses SHA-1 ? > > > SSLCertificateChainFile="C:Certificate\Public Key\WSD-2DNX4M3...cer" > > A '\' is missing after ':'. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat Internal Architect for JSP compilation?
As Suggested by @Tim i used precompiled jsp feature and now i am not
getting 500 error even i deleted the */tmp/tomcat** directory
@Bean
>
> public ServletContextInitializer preCompileJspsAtStartup() {
>
> return servletContext -> {
>
> Set jspPaths = servletContext.getResourcePaths("/WEB-INF/jsp/");
>
> if (jspPaths != null) {
>
> for (String jspPath : jspPaths) {
>
> if (jspPath.endsWith(".jsp")) {
>
> //logger.info("Registering JSP: " + jspPath);
>
> ServletRegistration.Dynamic reg = servletContext.addServlet("jspServlet_"
> + jspPath, "org.apache.jasper.servlet.JspServlet");
>
> reg.setInitParameter("jspFile", jspPath);
>
> reg.setLoadOnStartup(99);
>
> reg.addMapping(jspPath);
>
> }
>
> }
>
> } else {
>
> logger.error("No JSP files found in /WEB-INF/jsp/ directory");
>
> }
>
> };
>
> }
>
>
> private static String getResourcePath(ServletContext servletContext,
> String path) throws MalformedURLException {
>
> URL resourceUrl = servletContext.getResource(path);
>
> return resourceUrl != null ? resourceUrl.getPath() : null;
>
> }
>
But still I am not able to find the root cause why tomcat is throwing the
error *500(ClassNotFoundException)* when deleting the /tmp/tomcat*
directory .
Observations
1- Application UI open A.jsp
2- Now Delete /tmp/tomcat*/ Directory
3- Access* A.jsp* it will work
4- Access *B.jsp* it will throw 500(ClassNotFoundException)
5- Access C.jsp it will work and regenerate the */tmp/tomcat** directory
6- B.jsp will not work upto the time i won't restart the tomcat.
On Tue, Mar 26, 2024 at 8:39 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Subodh,
>
> On 3/26/24 06:59, Subodh Joshi wrote:
> > I am planning to do same now and may be we will use the property
> >
> > *server.tomcat.basedir*
> >
> > But this may create another issue ,it will grow the size of the folder.
>
> What makes you say that?
>
> > Is this possible in the coming release tomcat/embedded tomcat give a
> > feature to delete the basedir at the tomcat restart/start and
> > recreate it?
>
> This sounds more like a deployment detail and not a Tomcat-launch
> detail. Since you are using Spring Boot, why not just delete the
> directory from your own code before Tomcat launches?
>
> > One more thing is unanswered after deleting the tomcat folder why first
> > page clicked is throwing 500 error with ClassNotFoundException if its not
> > accessed before deleting the tomcat folder?
>
> I'm sorry, I can't answer that without spending a lot of time looking at
> your environmemnt.
>
> If you stop deleting the directory while Tomcat is running and it stops
> returning 500 responses, then I think you have solved your problem
> without discovering the absolute root-cause of the problem. But you are
> pulling the rug out from underneath a running application and expecting
> it to work without failing. I think that's not a realistic expectation.
> Tomcat relies on its local environment being stable. Dont' destabilize it.
>
> If you absolutely need Tomcat to not-fail under thes conditions, we'd be
> happy to have you research it and provide a patch or pull-request.
>
> -chris
>
> > On Fri, Mar 22, 2024 at 7:01 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Subodh,
> >>
> >> On 3/22/24 01:36, Subodh Joshi wrote:
> >>> Hi Chris
> >>>
> >>> Thanks for your response.
> >>>
> >>> So i added below properties in application.properties file
> >>>
> spring.mvc.cache-control.cache-allowed=false
>
> and then Deleted the /tmp/tomcat directory . So now when i restart the
> >>> server A.jsp only fail with 500 error (ClassNotFoundException) as this
> is
> >>> first page which i was trying to load, rest JSP pages working fine
> >> without
> >>> any issue .
> >>>
> >>> Why i am doing this exercise?
> >>> In our some of the deployed linux environment many clients are
> >> complaining
> >>> about this issue , We tried to monitor who actually deleting these
> >>> /tmp/tomcat folder but still we are not able to figure it out and we
> are
> >>> not able to reproduce it . So i have to do reproduce it manually
> deleting
> >>> the /tmp/tomcat directory.
> >>
> >> What if you don't use /tmp as your work directory location? /tmp is
> >> supposed to be for actually temporary files. These files could live for
> >> decades if you never changed your source .jsp files or re-deployed your
> >> application.
> >>
> >> -chris
> >>
> >>> On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz <
> >>> ch...@christopherschultz.net> wrote:
> >>>
> Subudh,
>
> On 3/21/24 07:32, Subodh Joshi wrote:
> > Expert,
> >
> > Recently i came across a issue and i was getting no clue what was
> going
> on
> > wrong with the Application.
> >
> > So here is the issue , we were getting following issue in our web
> > application(Springboot+Embedded Tomcat) which is deployed into Linux
> machine
> >
> > java.lang.ClassNotFoundException:
> >>
