Re: javax -> jakarta rename

There are imo 3 ways we can deal with the migration. All of them assume that all of our ASF projects migrate the affected packages from javax.* to jakarta.*. A.) of course have all the customer code and libs migrated to jakarta.*. B.) ClassTransformer + ClassLoader. The ClassTransformer

Re: CDI support improvements

> Am 12.06.2019 um 15:35 schrieb Rémy Maucherat : > > That did not seem very practical to me so the said code is quite Tomcat-like > right now and most importantly it needs the fixes made in 9.0.21, so it won't > work with any older Tomcat. If you really can take it over > (and

Re: CDI support improvements

Hi folks! Really happy to see so much love and interest for all those awesome ASF projects! Rémy's enhancements are great - the better and cleaner the integration, the better for all those projects. But Romain and David are also correct: it's very easy to become a committer on all the

Re: Jakarta package change

Tue, May 7, 2019 at 7:33 PM Mark Struberg > wrote: > >> Hi folks! >> >> Yes, I'm right now playing with it. >> For a little more background and overview I've written up a blog post: >> >> https://struberg.wordpress.com/2019/05/06/the-way-forward-for-j

Re: Jakarta package change

with "old" applications >> will >>> still have an up to date fully compatible container for them. >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which >> would >>> provide a container for users who want to move to the new &qu

Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54

did you debug in org.apache.catalina.connector.Request#recycle? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-08-04 22:37 GMT+02:00 Mark Struberg strub...@yahoo.de: yea

request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54

Hi! I've recently found out that getUserPrincipal() returns null in a Listener [1].  I remember that this used to return the correct Principal in older versions (might be some time already).  Also from reading the spec I assumed it should work. Any infos on this? LieGrue, strub [1] 

Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54

principal AFAIR, isn't it? 2014-08-04 19:33 GMT+02:00 Mark Struberg strub...@yahoo.de: Hi! I've recently found out that getUserPrincipal() returns null in a Listener [1]. I remember that this used to return the correct Principal in older versions (might be some time already

Re: apis @asf

Well, not sure it has to do with it, but since 7.0.53 I get a MethodNotFound in a project which used to work since years if the EL has a null parameter: java.lang.NoSuchMethodException: de.jaxenter.eesummit.caroline.gui.beans.Menu$$OwbNormalScopeProxy0.activateMenuItem(null)

Re: tomcat 7.0.29 startup time

Thomas wrote: On 25/07/2012 17:00, Mark Struberg wrote: Hi Lords and Ladies! I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 45s, 7.0.29 90s). I'm aware that 7.0.29 now does the scanning

Re: tomcat 7.0.29 startup time

tried the empty absolute ordering again and it doesn't seem to help. I fear that @HandlesTypes again has higher precedence than the web-fragment ordering/disabling. LieGrue, strub - Original Message - From: Mark Struberg strub...@yahoo.de To: Tomcat Developers List dev

tomcat 7.0.29 startup time

Hi Lords and Ladies! I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 45s, 7.0.29 90s). I'm aware that 7.0.29 now does the scanning for ServletContainerInitializer even if version=2.5 is specified. But there shall no class