Re: Side effect of Tomcat 10.1.20 with Freemarker
On 07/06/2024 09:04, Jeroen Hoffman wrote: On 06-Jun-24 18:17, Mark Thomas wrote: On 06/06/2024 11:01, Jeroen Hoffman wrote: Hi all, We've found a side effect of change #68721 [1] in Tomcat 10.1.20 that we'd like to notify you about. We're using Apache Freemarker for back-end templating, and its NodeModel class uses reflection to determine what classes to use for xpath, thereby catching IllegalAccessError, see [2]. Per change #68721 a IllegalAccessError is caught as LinkageError and turned into a Throwable, NoClassDefFoundError in our case, see [3], and then falls through that block in NodeModel and errors out. So this change in Tomcat alters the behaviour in Freemarker, which I assume was unexpected. We can (and must) work around it, preventing the IllegalAccessError, but still, maybe you'd like to improve again or have other thoughts? How are you getting from the original IllegalAccessError to a NoClassDefFoundError? Tomcat should re-throw the original IllegalAccessError. Small correction from my side: WebappClassLoaderBase throws a ClassNotFoundException (not NoClassDefFoundError) at the end of #loadClass (line 1353). It's not re-throwing the original IllegalAccessError because the call to #findLoadedClass0(name) at line 2361 is NOT throwing anything, just returns null and then the ClassNotFoundException is thrown. This specific case is about an anonymous inner class that implements PrefixResolver from the java.xml module, see https://github.com/apache/freemarker/blob/2.3/freemarker-core/src/main/java/freemarker/ext/dom/SunInternalXalanXPathSupport.java Got it. Thanks for the explanation. I need to confirm that it doesn't break the original fix but my plan is to check clazz after line 2311 and rethrow the original exception if it is null. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Side effect of Tomcat 10.1.20 with Freemarker
On 11/06/2024 12:30, Mark Thomas wrote: I need to confirm that it doesn't break the original fix but my plan is to check clazz after line 2311 and rethrow the original exception if it is null. Testing with the original reproducer looks good. Fixed in: - 11.0.x for 11.0.0-M21 onwards - 10.1.x for 10.1.25 onwards - 9.0.x for 9.0.90 onwards Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mysterious websocket disconnection--no logs
On 09/06/2024 01:08, Flaviu Tamas wrote: I'm writing some tests for my Spring Boot application, which uses tomcat-embed-websocket-10.1.18. When I send a message to the socket from handleVideoFrame, all I see is .WebSocketAnnotationMethodMessageHandler : Invoking VideoStreamController#handleVideoFrame[3 args] o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session 3b7fc290-eeb3-a86c-a465-8826819f3bde I can turn debug logging on for org.apache.tomcat.websocket.WsSession, which give me a bit more detail, but this is detail that the application user is unlikely to care about (some sort of internal ID that I don't think is exposed anywhere else) .WebSocketAnnotationMethodMessageHandler : Invoking VideoStreamController#handleVideoFrame[3 args] org.apache.tomcat.websocket.WsSession: Closing WebSocket session [3] o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session a77dcddd-877e-1d5a-8dd2-daf3f38395f7 This is especially frustrating because this log line has complete context. If I place a breakpoint in WsSession.doClose, I can see that the error is "The decoded text message was too big for the output buffer and the endpoint does not support partial messages", which does help me solve my problem. It would be nice if this message was exposed to the user, either by default, or at the very least in the debug logs. The message is sent to the user/client as part of the WebSocket close message. If the client doesn't expose that to the user, there isn't much Tomcat can do. Mark - 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
Mark,
On 6/10/24 14:56, Timothy Resh wrote:
After much debugging, I have found the issue in my situation. In the
server.xml file, you must put keystoreType="PKCS12" for it to recognize the
keystore properly.
That doesn't make any sense to me. Not a single one of your previous
posts has been using a keystore file at all for Tomcat. You did show how
you assembled a (rather complicated) PKCS12 keystore file using a
combination of openssl and keytool in your message from 25 March but
this is the only place in your configuration file I see that file:
SSLPassword="${KSENC(6qkaMErQ==; C:\Certificate\Keystore\Vessel.p12)}"
I have *no idea* what you are doing in there, but I assumed that
keystore contained some kind of password and not a certificate or RSA key.
-chris
On Fri, Apr 5, 2024 at 4:27 AM Roberto Benedetti <
roberto.benede...@dedalus.eu> 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.
Keystore Explorer uses Bouncy Castle (https://www.bouncycastle.org/) as
provider for JCE.
If your JRE/JDK does not provide some algorithm you could use Bouncy
Castle as well.
Regards,
Roberto
-
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: Tomcat 9: Java 11 to Java 17
Ryan, Word-wrapping didn't help on this one... On 6/10/24 15:44, Ryan Esch wrote: Hi folks,I have a webapp running Apache Tomcat 9.0.67 with Java 11, using JASPIC for authentication. For reference, using these: org.apache.tomcat tomcat-catalina 9.0.85 org.apache.tomcat catalina 6.0.53 Are you using two different versions of Tomcat glued together? tomcat-catalina is 9.0.85 (and not 9.0.67 as you claim above) but also catalina is 6.0.53? You might want to sort this out before moving forward any more. This works.I need to get this running with Java 17. I've updated my javax classes to jakarta and my JASPIC dependencies to: org.apache.tomcat tomcat-jaspic-api 11.0.0-M5 org.apache.tomcat tomcat-catalina 11.0.0-M5 Those are Tomcat dependencies. Don't you have any dependencies on like servlet-api and jaspic and things like that? Those are much more important than depending on Tomcat itself. Unless you are actually launching Tomcat from Maven or using Tomcat as an embedded server inside your application, you shouldn't have any Maven dependencies on Tomcat *at all*. You should be using the servlet-api and related artifacts instead. Also... you have chosen Tomcat 11 dependencies, but you are deploying onto Tomcat 9.0.something. Not going to work. These are built with Java 17. My webapp compiles and builds. But at runtime, I get errors like this: java.lang.VerifyError: Bad type on operand stackException Details: Reason: Type 'org/apache/catalina/authenticator/jaspic/AuthConfigFactoryImpl' (current frame, stack[4]) is not assignable to 'jakarta/security/auth/message/config/AuthConfigFactory' Specifically, this does not cause any issues: AuthConfigFactory factory = new AuthConfigFactoryImpl(); However, if I call any method on this factory, I see the above Error.I can't seem to figure out the cause. I don't see any old javax AuthConfig classes in the dependencies.Anyone familiar with this? This is definitely a javax/jakarta impedance issue. I would go back to your pom and see if you are able to remove Tomcat completely. You should really be using these dependencies instead: jakarta.platform jakarta.jakartaee-api 8.0.0 provided This is for the servlet API itself. JASPIC (now "Jakarta Authentication") is of course a separate artifact. Once your application is building to a WAR properly, try deploying it into Tomcat 10 or Tomcat 11. As Chuck says, Tomcat 10 is the first version of Tomcat that supports the Jakarta APIs. Going *way back to the beginning*, getting your application working with Java 17 should have been trivial: just install Java 17 and run everything you already had without any changes whatsoever. You shouldn't have even needed to recompile anything. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Excluding specific files when creating WAR files?
James, On 6/10/24 13:09, James H. H. Lampert wrote: Please forgive me if this is a RTFM issue, or if it's outside the scope of this List (and this isn't exactly the first time I've imposed upon the friendly nature of this List, knowing that it's a much more forgiving environment than a lot of StackExchange forums are). I've just been alerted that our WAR files contain ".DS_Store" (Mac OS desktop information) files. So far as I'm aware, it's difficult or impossible to keep Mac OS from generating these files, but is there some WAR file generation parameter that can be used to exclude them? The short answer to this is "yes" but the slightly longer answer is "ask your developers to arrange for artifacts such as these to be ignored when building ZIP files." Others are offering some specifics, but if it's not your job to package the ZIP files then, well, don't bother to try to find the solution yourself. Just tell your devs to fix this. If you want to fix your existing JAR files, you can do this if you are on a UNIX-like system and have the "zip" utility installed: $ zip -d data.zip "*/.DS_Store" The "*" here should expand to include all prefixes so it should remove these files from all directories. Back to the original issue: .DS_Store files in ZIP files [is a security issue] as claimed by your customer's security scan. Eh... yeah, sure I guess. But it's not going to leak very much information from your developers' machines. The real problem would be if *other* files from your developers machines are ending up in the build... the only thing the presence of the .DS_Store files would be to indicate that other (usually more sensitive) files are also available. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
