On Tue, Oct 8, 2024 at 7:51 AM Christopher Schultz <ch...@christopherschultz.net> wrote: > > All, > > These are some brief notes I took during today's meeting about community > expectations and desires for Tomcat 12. > > I think it's worth possibly separating these out into individual > discussion threads so things don't get too convoluted in one major > thread. So if anyone wants to lead the conversation on any of the below > items, please post a new thread to get the conversation going.
Well, I'm going to go for quick feedback first :) > == Items Discussed at Coc Denver > > Formally certify a non-milestone release of Tomcat 11 for Jakarta EE APIs. > > QUIC - requires some more thought. What does OpenSSL provide? What about > collaboration options with other projects? I think OpenSSL provides everything, but it's so huge I don't see how it will ever be stable enough. h2 is still causing a lot of problems after all that time, so this is far worse. > Keep JASPIC/JEE Authentication. Some straightforward tutorials or > "getting started" types of things would be helpful. Ok. > OCSP for client certs - let’s not do this as OCSP might be disappearing > entirely. I think the concept is great, but it adds another reason for a service to be unavailable. That's probably not good. > FFM - nobody cares about tcnative, so FFM sounds like a good move. When you say "nobody cares about tcnative" I suppose it means "nobody wants to have to care about tcnative" ? FFM is probably very nice (it is reflection for native code after all) but it needs Java 25. Maybe at some point the plan is to say that if you want OpenSSL, you have to use Java 25 ? If this is not done, then tcnative basically never gets dropped. > Some interest in encryption for multicast clustering. Ok. > No opinions on WebTransport. It looks interesting. > No opinions on WebSocket over h2. No opinion either. > Should Tomcat stop applications doing stupid things such as explicitly > setting chunked encoding? Mixed responses. Definitely don't want any > significant performance impact on applications that are well-behaved. > Could this be an optional Valve that simply enforces these rules? Maybe ? > AJP - definite proposal to remove from T12 (schultz), announce our > intention to deprecate mod_jk in favor of moving features into > mod_proxy_ajp and mod_proxy_balancer. Ok. > OAuth(2) - based authentication e.g. to allow Tomcat to authenticate > users from a public identity provider such as Google, fb, etc. - Shawn > and schultz were interested in the concept. Are there any JASPIC-based > providers that already provide this type of thing? Mark did stuff with this one in the past: https://github.com/phillipgreenii/google-oauth-2.0-serverauthmodule > No opinions on Maven Tomcat Plugin. Possible Google SoC project to > resurrect this and get it working with a current Tomcat version? People like it, but nobody likes it enough to work on it. > == > > In the pub track at the end of the day, I proposed bringing back the BIO > connector with Virtual Threads as the magic which makes everything work. > markt is convinced the idea has merit and on initial hand-waving > conversation, he thinks that maybe just maybe Tomcat 12 could dump both > NIO and NIO2 connectors, the Poller and other complexities. Servlet > async and Websocket both seem to have solutions based upon BIO and VT. > The question is whether or not VT will reach the level of maturity > required for Tomcat and downstream users to rely on it for production > workloads. Our initial sense is that yes, the promises of VT will be > realized in the timeframe during which Tomcat 12 will become stable. This still looks difficult to me, as native code support cannot be fixed. Of course polling is complex but it works. I don't expect this to change, so VT would remain a niche use. Is there anything new that changes this ? Rémy > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
