RE: [Semi OT] Suggestion: Maven repository for Tomcat native library
Tomcat native gives much better SSL connection performance, they say. At least in Windows. I have not personally performed any tests though. https://tomcat.apache.org/tomcat-9.0-doc/apr.html -Harri -Original Message- From: Christopher Schultz Sent: lauantai 10. elokuuta 2024 0.51 To: users@tomcat.apache.org Subject: Re: [Semi OT] Suggestion: Maven repository for Tomcat native library Harri, On 8/9/24 05:56, Harri Pesonen wrote: > Hello, currently Tomcat native library needs to be downloaded manually from > here: > > https://tomcat.apache.org/download-native.cgi > > It would be better to download it from Maven repository, so that we could > upgrade the version easier using Maven scripts. > Also we could see easier when the version needs to be upgraded. > Normally Maven repository contains only Java artifacts, but it is possible to > upload binaries as well. > For example Microsoft JDBC driver has Java .jar in on artifact, and native > .dll in separate artifact: > > https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64 > > What say you? I'm just academically curious: what do you need tcnative for? -chris - 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
mod_jk retry continuing existing stream?
I have mod_jk load balancing over several back-end Java processes which embed Tomcat. When I Ctrl-C one of those processes, a server-sent-event response stream (which has already sent a number of events) does not end from a client perspective. Rather the original request is retried against the next server and its response is simply added to the original stream from the client's perspective. That is just plain weird - and doesn't make sense to me at all in terms of retry handling. Any pointers/info on this would be much appreciated. -- Jess Holle P.S. The stream is generated via async servlet request/response via Spring WebFlux/Reactor.
Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?
I know I have at least one Tomcat 9 installation running on an IBM Midrange box (namely our cloud box). But I can't remember whether there are any "gotchas" for going from 8.5 to 9, with Tomcat handling the HTTPS itself, using a Java Keystore, and opening Manager to specific IP addresses. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?
> On Aug 12, 2024, at 19:02, James H. H. Lampert > wrote: > > I know I have at least one Tomcat 9 installation running on an IBM Midrange > box (namely our cloud box). > > But I can't remember whether there are any "gotchas" for going from 8.5 to 9, > with Tomcat handling the HTTPS itself, using a Java Keystore, and opening > Manager to specific IP addresses. Start here: https://tomcat.apache.org/migration-9.html Looks like there are a couple of things that might catch one out, but other than Comet being removed, they appear to be fairly easy to address. - Chuck
Lightweight container for bare "void service(req,res)", maybe through custom Engine implementation?
Hi, I have an application which is built on top of Tomcat, currently 10.1. The part of the application that interfaces with Tomcat is a single custom class that extends jakarta.servlet.GenericServlet[1]: This servlet implements the abstract void "service" method, which 1. reads the request headers, parameters and parts (for multipart requests), 2. does the request processing (through delegated web and business logic layers), 3. sets some headers on (Http)ServletResponse and 4. fills the OutputStream of the (Http)ServletResponse. The application does not use JSP, EL, no filters, ... The web.xml consists of 1 Servlet definition and 1 Servlet mapping. The rest of the application is decoupled from the web container technology and doesn't know anything from jakarta.servlet.*. Therefore, I could maybe even switch to NanoHTTPD.[2] But I love Tomcat being so *perfectly maintained*, proven and reliable! <3 THANKS SO MUCH! And Tomcat offers HTTP/1.1 and HTTP/2 Connectors while NanoHTTPD seems to lack HTTP/2 support. But as so much of Tomcat is not used in this specific application, I thought if I could build a "shortcut" to reduce the parts involved in request processing and speed up reaction times. Something like building a web app on top of a "light" Tomcat skeleton, with only a few stacktrace lines involved for a request to be processed. From a first look, the Engine component / interface might be a starting point? And amazingly, with Tomcat we're free to configure custom implementation classes for lots of components, e.g. Engine.[3] So such an approach wouldn't mean to build a horribly to maintain fork with custom patches against Tomcat's source tree. Are you aware if someone did something like the devised "light" container before? Yours, Reg [1] https://jakarta.ee/specifications/servlet/4.0/apidocs/javax/servlet/genericservlet [2] https://github.com/NanoHttpd/nanohttpd [3] https://tomcat.apache.org/tomcat-10.1-doc/config/engine.html#Common_Attributes - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
