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 scanning be performed if metadata-complete="true" is set, right? The problem is that @HandlesTypes forces scanning. And regardless if you only scanning or the types registered via @HandlesTypes or searching for all - the startup time is almost the same. This is because the most expensive part is the file and zip handling... So even if the webapp is metadata-complete, it still performs all the class scanning. You can prove this by simply adding Apache MyFaces to a sample webapp. Any other sample which utilizes a ServletContainerInitializer and has @HandlesTypes will also do the job. In my case it's even more fatal: I have the FacesServlet configured via web.xml, so the whole MyFaces ServletContextInitializer is not used at all... Any ideas how we can ease the pain quickly? I know the Servlet-EG 'clarified' that only recently, but being an EG member myself I know exactly that this can be reverted if it only got 'recently clarified'. Nothing is set in stone until a final MR spec with an absolute binding wording got released. Mark, others, what about explaining the impact to the EG again and maybe they change their mind? For the long run you might be interested in commons-classscan we do over at commons atm. The idea is to have all sorts of ASF projects (tomcat, OpenWebBeans, OpenEJB, MyFaces, BVal, OpenJPA, ...) register their needs upfront and do the scanning only once. But it will take a bit until we have something to show off I fear as most of us are under heavy load in other ASF projects as well. LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat 7.0.29 startup time
Hi Mark,
thanks for the clarifications, highly appreciated!
As far as the empty goes: After reading the spec again
I've been down to that route as well. So far it didn't work out. Maybe I've
just done something wrong - will revisit and try again. Should the
only affect the jars with web-fragments, or does it
disable scanning of all jars then?
I also discovered another possible impact:
Our scenario is to use 1 tomcat installation as 'quasi EAR' container. We use
the shared.loader in conf/catalina.properties and set it to our own
${catalina.home}/applib directory which contains all our shared libraries
(myfaces, openwebbeans, openjpa, ...).
For what I did understand by reading the servlet-3.0 spec is that only
fragments and classes in either WEB-INF/classes or WEB-INF/lib/*.jar shall get
scanned by tomcat, right? But it seems that also all our shared.loader jars
will get scanned as well. I have not explicitly debugged thru, but from the
startup times I see no other explanation as our WARs contain almost no jars.
If I set the jarToSkip=*.jar then the boot time is back to normal.
Is there an explanation in the servlet spec, or does tomcat scan a bit too much
yet?
txs and LieGrue,
strub
- Original Message -
> From: Mark Thomas
> To: Tomcat Developers List
> Cc:
> Sent: Saturday, July 28, 2012 2:36 AM
> Subject: Re: tomcat 7.0.29 startup time
>
> On 28/07/2012 00:25, Mark 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 for
>>> ServletContainerInitializer even if version=2.5 is specified. But
>>> there shall no class scanning be performed if
>>> metadata-complete="true" is set, right?
>>
>> Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
>> - ServletContainerInitializer cannot be disabled
>> - If a ServletContainerInitializer is found, then class-scanning will
>> take place
>>
>>> Any ideas how we can ease the pain quickly?
>>
>> The only option I see is a custom (non-spec compliant) Tomcat specific
>> feature that disables all of this.
>
> Ah. See the latest developments on
> http://java.net/jira/browse/SERVLET_SPEC-36
>
> Using an absolute ordering that specifies no fragments along with
> metadata-complete=true should do the trick.
>
> Mark
>
>
> -
> 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
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
> To: Tomcat Developers List
> Cc:
> Sent: Sunday, July 29, 2012 1:14 PM
> Subject: Re: tomcat 7.0.29 startup time
>
> Hi Mark,
>
> thanks for the clarifications, highly appreciated!
>
> As far as the empty goes: After reading the spec
> again I've been down to that route as well. So far it didn't work out.
> Maybe I've just done something wrong - will revisit and try again. Should
> the only affect the jars with web-fragments, or does
> it disable scanning of all jars then?
>
>
>
> I also discovered another possible impact:
>
> Our scenario is to use 1 tomcat installation as 'quasi EAR' container.
> We use the shared.loader in conf/catalina.properties and set it to our own
> ${catalina.home}/applib directory which contains all our shared libraries
> (myfaces, openwebbeans, openjpa, ...).
> For what I did understand by reading the servlet-3.0 spec is that only
> fragments
> and classes in either WEB-INF/classes or WEB-INF/lib/*.jar shall get scanned
> by
> tomcat, right? But it seems that also all our shared.loader jars will get
> scanned as well. I have not explicitly debugged thru, but from the startup
> times
> I see no other explanation as our WARs contain almost no jars.
>
> If I set the jarToSkip=*.jar then the boot time is back to normal.
>
>
> Is there an explanation in the servlet spec, or does tomcat scan a bit too
> much
> yet?
>
>
> txs and LieGrue,
> strub
>
>
>
> - Original Message -
>> From: Mark Thomas
>> To: Tomcat Developers List
>> Cc:
>> Sent: Saturday, July 28, 2012 2:36 AM
>> Subject: Re: tomcat 7.0.29 startup time
>>
>> On 28/07/2012 00:25, Mark 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 for
>>>> ServletContainerInitializer even if version=2.5 is specified. But
>>>> there shall no class scanning be performed if
>>>> metadata-complete="true" is set, right?
>>>
>>> Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
>>> - ServletContainerInitializer cannot be disabled
>>> - If a ServletContainerInitializer is found, then class-scanning will
>>> take place
>>>
>>>> Any ideas how we can ease the pain quickly?
>>>
>>> The only option I see is a custom (non-spec compliant) Tomcat specific
>>> feature that disables all of this.
>>
>> Ah. See the latest developments on
>> http://java.net/jira/browse/SERVLET_SPEC-36
>>
>> Using an absolute ordering that specifies no fragments along with
>> metadata-complete=true should do the trick.
>>
>> Mark
>>
>>
>> -
>> 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
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
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-jakartaee-packages/ I've also already started to migrate a few spec packages. The current work in progress is available here: https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ I've already test-migrated over Apache OpenWebBeans CDI container. Of course with TCK and servlet integration disabled for now as Arquillian and Tomcat first needs to be ported. https://github.com/struberg/openwebbeans/tree/jakarta I'm right now tinkering with Tomcat. And boy, tomcat has way more dependencies than I'd like. And it would help if it would finally be migrated to use Maven, but I spare you that ;) As soon as I've something decently working then I'll share! LieGrue, strub > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : > > On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: > >> On 07/05/2019 08:05, Rémy Maucherat wrote: >>> Hi, >>> >>> Background information: >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ >>> >>> So this is obviously a large breaking change. While there are plenty of >>> options, there is a simple one too: >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the >>> APIs in Tomcat 9 can remain javax.* and users 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 "incompatible" >>> Jakarta specifications. >>> >>> This way, there's an appropriate container for everyone. Mark Struberg >>> proposed more elaborate strategies using classloader tricks on the ASF >>> members list, but I'm not sure this is even needed for Tomcat. >>> >>> Overall, the impact for Tomcat seems rather minimal given the maturity of >>> Tomcat and its expected support lifecycle for 9.x. >>> >>> Comments ? >> >> I think it is good we are thinking about options but too early to settle >> on any one solution. The solution we adopt is going to be largely >> dependent on what the API projects at Eclipse decide to do. >> >> Rather than announcing a solution, how about we announce that we will >> > > I agree, it is too early to decide and announce. Still, discussion is fine > (IMO) and unless the announced Jakarta change ends up not happening. We'll > indeed see what happens at Jakarta. > > >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that >> means supporting all the older versions of those specs as well. Exactly >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is >> just one possible option. >> > > +1, I was also thinking about "2030 at least" when I wrote "forever" > because it makes for a nice impressive announcement ! > > >> >> Mark >> >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years >> for typical support period + 5 years extension and rounded to the end of >> the year. >> > > Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
Yes, the first step is just trying out what we could have missed. And of course this would be tc-10. The first quick and dirty hack is alive: https://github.com/struberg/tomcat/tree/jakarta You first need to compile the geronimo-jakarta specs locally from https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ Then (don't slap me!) you have to run a mvn clean install in tomcat. This will just fire up the dependency resolution for those jakarta specs missing and copy them to target/dependency/*.jar Then run a standard ant There are really dirty parts in the change. mostly around everything XAResource related. Like LocalXAConnectionFactory and DataSourceXAConnectionFactory. Attention: I'm totally tired already and I've not run any tests yet. But at least it compiles again. have fun! LieGrue, strub > Am 07.05.2019 um 20:38 schrieb Rémy Maucherat : > > On 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-jakartaee-packages/ >> >> I've also already started to migrate a few spec packages. >> The current work in progress is available here: >> https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ >> >> I've already test-migrated over Apache OpenWebBeans CDI container. >> Of course with TCK and servlet integration disabled for now as Arquillian >> and Tomcat first needs to be ported. >> https://github.com/struberg/openwebbeans/tree/jakarta >> >> I'm right now tinkering with Tomcat. >> And boy, tomcat has way more dependencies than I'd like. >> And it would help if it would finally be migrated to use Maven, but I >> spare you that ;) >> >> As soon as I've something decently working then I'll share! >> > > Just so that things are clear, I think I am against any jakarta.* related > changes in Tomcat 9. It will stay on JakartaEE 8 no matter what, so it can > use javax.* and it should stay that way since this means guaranteed zero > impact for users. As is customary, the next major Tomcat version would > however have support for the next relevant specifications, so that in turn > would have to be jakarta.* (unless things change). I am not so sure this > next version would need dual support at all, but this is completely > undecided at this point. And I agree with Mark (T) that there are too many > unknowns and it's too early to make a decision. > > Rémy > > >> >> LieGrue, >> strub >> >>> Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : >>> >>> On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: >>> >>>> On 07/05/2019 08:05, Rémy Maucherat wrote: >>>>> Hi, >>>>> >>>>> Background information: >>>>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ >>>>> >>>>> So this is obviously a large breaking change. While there are plenty of >>>>> options, there is a simple one too: >>>>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all >> the >>>>> APIs in Tomcat 9 can remain javax.* and users 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 >> "incompatible" >>>>> Jakarta specifications. >>>>> >>>>> This way, there's an appropriate container for everyone. Mark Struberg >>>>> proposed more elaborate strategies using classloader tricks on the ASF >>>>> members list, but I'm not sure this is even needed for Tomcat. >>>>> >>>>> Overall, the impact for Tomcat seems rather minimal given the maturity >> of >>>>> Tomcat and its expected support lifecycle for 9.x. >>>>> >>>>> Comments ? >>>> >>>> I think it is good we are thinking about options but too early to settle >>>> on any one solution. The solution we adopt is going to be largely >>>> dependent on what the API projects at Eclipse decide to do. >>>> >>>> Rather than announcing a solution, how about we announce that we will >>>> >>> >>> I agree, it is too early
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 involved projects, especially for people known to deliver outstanding code and to be excellent community players! So at the end I really don't care much in which project stuff ends up. There are just a few ideas I'd like to have you think about: A.) There should be a clear 'dependency graph'. This is not so much a maven issue but really more a question of clear design. Tomcat is clearly the foundation of an EE server. It provides the ClassLoader setup, the servlet engine, etc. Tomcat provides abstract ways to integrate whatever wants to integrate with it via abstraction mechanisms. This might be CDI or Spring or Guice, or whatever! On top of this comes the CDI container who manages the instances. So all those parts live in OWB. Including the integration. So I'd keep the Tomcat integration as part of OWB. Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI container and TomEE as fully blown JavaEE server. Having a build reference to TomEE or OWB in Tomcat would introduce cycles in our builds. This is not really a good thing. B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they are searching for a bug or even want to contribute a new feature. makes sense? txs and LieGrue, strub > Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau : > > Hell Rémy, > > I commented inline > > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat a écrit : > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau > wrote: > My 2cts would be that we have the luck to be fully ASF here so each project > can likely get back its missing piece(s) and we stay overall consistent > instead of creating yet another fork in our beloved foundation (we already > have some concurrent servers or even jdbc pools which does not help much user > land). > > @Rémy do you track the issues you encounter somewhere? > For instance "CXF is not user friendly" but once you have CDI you get CXF set > up just adding a servlet. Here, an initializer would have been friendly but > then you would encounter the servlet initializer ordering issue. > > Ok :) > > So: > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really > figure out what's mandatory (there's a WHICH_JARS file, so that cannot be > that good). > > Depends, if you use maven it is fine ;). > > Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or > jakarta jars) you just need: > > org.apache.cxf:cxf-core:3.3.2 > org.apache.cxf:cxf-rt-security:3.3.2 > org.apache.cxf:cxf-rt-transports-http:3.3.2 > org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2 > org.apache.cxf:cxf-integration-cdi:3.3.2 > org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target > Microprofile you need it) > > - (Ok I figured it out) Looking at the integration(s), I quickly notice there > are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and > cxf-rt-transports-http (did I miss any ?). They all need that I define a > Servlet it seems (no idea why at least some of these don't do it for me). > > There are two main concepts: the integration (cdi, spring, blueprint, ) > and the transport (http, jms, ...). Http transport goes through the servlet > and the integration relies on the transport to forward the messages (request) > to the CXF server which does the link with the beans. > > - After getting somewhere and trying a mp health test with your Geronimo > Health CDI bundle, I got: > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both > org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks > and > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks > are equal candidates for handling the current request which can lead to > unpredictable results > 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse > javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error > at > org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79) > at > org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89) > at > org.a
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 un-Tomcatize the code, I suppose), no problem. There are multiple options on the table. One would be to have this code checked via reflection. The other is to just add a new module which is for tomcat9++ > > > B.) We should also try to keep code and responsibilities at a single place > > and shall try to avoid duplications. This has nothing to do with > > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a > > lot to do with users knowing exactly where to look at if they > > are searching for a bug or even want to contribute a new feature. > > Ok, so I guess I don't need to do anything further in that area since you > prefer to continue covering it. I'll move on to other items on my todo list > then. > We need a JIRA ticket in OWB with a description of the suggested improvements. After all we'd love to understand and document what improvements you would like to implement. And of course a patch would also be highly welcome! txs and LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
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 transforms all usage of affected packages from javax.* to jakarta.*. when the classes get loaded. The ClassLoader redirects any META-INF/services/javax.* java.util.ServiceLoader files and serves them as META-INF/services/jakarta.* C.) pretty much like B.) but as Apache Maven plugin at build time. It could provide the auto-migrated parts as attached artifact. Btw, I've done plenty of test migration a year ago already http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ https://github.com/struberg/tomcat/tree/jakarta https://github.com/struberg/openwebbeans/tree/jakarta LieGrue, strub > Am 25.12.2019 um 09:26 schrieb Romain Manni-Bucau : > > I see a lot of value to the runtime solution cause it is the only one > enabling an ops only migration so for all the softwares in "run only" phase > it is the only option. However the agent or transformer is the least invasive > solution cause it does not require to patch core libs and will avoid app > dependencies conflicts/issues (assuming asm is already there as in > tomee/meecrowave or shaded with relocation). > > Just my 2 cts > > Le mer. 25 déc. 2019 à 04:47, Adam Rauch a écrit : > > On 12/21/2019 11:49 AM, Mark Thomas wrote: > > On 21/12/2019 17:45, Adam Rauch wrote: > > > > > > > >> Yes, I see that 9.x javax.* will be supported for a long time and I'm > >> all in favor of killing off deprecated EE libraries. I want to encourage > >> our users to migrate to Tomcat 10.x and future releases as quickly as > >> possible, but I'm concerned that 9.x to 10.x will be a very difficult > >> transition for those who deploy webapps like the one we develop. With > >> the current plan, I don't see a scenario where our users can upgrade to > >> the next release of Tomcat, test that change, and then upgrade our > >> webapp. Because of the package rename, they will need to be upgraded in > >> lockstep, which has never been the case before. I see the value of a > >> short-term "transition" release that helps ease this burden by > >> supporting webapps using either package, but if others don't, then never > >> mind. > > I think the ideal migration strategy is going to vary for different > > users. Personally, I think an approach that largely mirrors what the > > Jakarta projects are going (i.e. just the package rename, nothing else) > > and doing that for the container and the app at the same time is the way > > to go in the majority of cases but I appreciate that that is just my view. > > > >> Maybe I've misunderstood the migration tool, but it looks like a great > >> tool for developers like me, not a tool that will directly help > >> non-developers who deploy pre-built Tomcat webapps. > > The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9, > > run it through this migration tool and then run the migrated app on > > Tomcat 10. We aren't there yet (I've only tested a JSTL API and > > implementation) but my intention is to use apps like Jira to test it. > > > >> As for Romain's question about doing the transformations in the > >> classloader, I started with a classloader approach (my classloader > >> responded to requests for "javax.servlet.*" classes with their > >> "jakarta.servlet.*" counterparts). I backed away because these classes > >> then needed to be manipulated so they'd match the javax interfaces' > >> expectations, but I haven't used ASM before. > > This is one of the approaches considered in previous discussions. It is, > > essentially, what the migration tool does. I think it is better to do > > this conversion in advance rather than take the performance hit in a > > running application. It is actually fairly simple to do as you only need > > to modify the String constants. > > > >> And this part of the > >> problem (my webapp requesting javax classes that no longer exist in > >> Tomcat) was easily solved by simply including those classes in my jar. > >> The more interesting problem was adapting the objects passed in the > >> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g., > >> Filter, Servlet, FilterChain); I'm not sure a classloader would help > >> there. But if someone can come up with a simpler classloader (or dynamic > >> proxy, et al)-based approach, then I'm all for it. > > I spent a bit of time thinking about this but didn't get as far as > > coding it. I came to the conclusion it could get very messy once you > > start wrapping requests and dispatching them and decided to focus on the > > migration tool instead. > > > > Overall, I think it is good that there are a range of tools supporting a > > range of approaches. As users start the migration progress, hopefully > > we'll get some feedback and we can re
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) java.lang.Class.getMethod(Class.java:1665) javax.el.BeanELResolver.invoke(BeanELResolver.java:394) javax.el.CompositeELResolver.invoke(CompositeELResolver.java:225) org.apache.el.parser.AstValue.getValue(AstValue.java:173) org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184) org.apache.webbeans.el22.WrappedValueExpression.getValue(WrappedValueExpression.java:70) Switching back only the tomcat-jasper-el.jar to 7.0.52 fixes the issue. The difference between those 2 versions is that in BeanELResolver of 7.0.53 I get a paramTyps[1] which contains a null value whereas in 7.0.52 and earlier the paramTypes itself is null. LieGrue, strub On Friday, 16 May 2014, 20:53, Romain Manni-Bucau wrote: > > >Hi > >svn copy would be at least a nice solution to avoid kind of forks > >For sure would be great to aligned it both impl. I think geronimo is >the place since most of project are using these APIs (tomee, openejb, >openwebbeans, bval, jcs soon, openjpa, ...) > >about the bug the type parameter resolution is not done in resolver >where before invoke was passing correct types. Didnt check the spec >about it. > >Not sure the work needed to go this way, any idea how we can go further? > > > > >Romain Manni-Bucau >Twitter: @rmannibucau >Blog: http://rmannibucau.wordpress.com/ >LinkedIn: http://fr.linkedin.com/in/rmannibucau >Github: https://github.com/rmannibucau > > > >2014-05-16 16:32 GMT+02:00 Mark Thomas : >> On 16/05/2014 07:59, Romain Manni-Bucau wrote: >>> Hello guys, >>> >>> Hope I didnt miss a thread dealing with it, if so please just redirect me. >>> >>> Tomcat made the choice to do its own API jars. That's not a big deal >>> by itself but wonder why not putting them with all "EE" api jars of >>> Apache, ie in geronimo specs subproject: >>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/ >> >> I suspect it stems from the fact the Tomcat was originally the reference >> implementation for a number of those. >> >>> It concerns mainly: >>> * el >>> * websocket >>> * jsp >>> * servlet >>> >>> Just to give you a bit more background, this question doesn't come >>> from nowhere. In TomEE we use geronimo API for almost everything >>> excepted some tomcat provided apis (servlet, jsp) until today. But >>> since recent Tomcat 7 got - thanks to Tomcat 8 - a refactoring of EL >>> part, geronimo-el and tomcat-el were no more compatible. In other >>> words TomEE was broken cause AstValue was refactored and method >>> matching more dedicated to BeanELResolver in tomcat but not in >>> geronimo. >> >> Doesn't that simply mean that the refactoring in Tomcat has exposed a >> bug in the Geronimo EL API? >> >>> Wonder if we should/can try to get something consistent accross ASF. >> >> Assuming that Geronimo is using the Tomcat implementations I wonder why >> the project felt the need to produce their own API JARs. Or are they >> just (old?) copies taken from Tomcat originally? >> >>> wdyt? >> >> From experience with re-using components from Commons, Tomcat would >> almost certainly want to keep a local copy - even if that was an svn >> copy of some common version - else releases can start to experience >> noticeable delays waiting on a release of a dependency. >> >> Mark >> >> >> - >> 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
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] http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityListener.java
Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54
yea exactly. But the user IS authenticated! And later in the Filter getUserPrincipal() returns the correct Principal. But in the ServletRequestListener (invoked in the same request of course) it is null. Either it should always be null, or never! LieGrue, strub On Monday, 4 August 2014, 22:12, Jean-Louis MONTEIRO wrote: > > >oups thanks Romain > > >2014-08-04 22:09 GMT+02:00 Romain Manni-Bucau : > >> "Returns a java.security.Principal object containing the name of the >> current authenticated user. If the user has not been authenticated, >> the method returns null." >> >> >> 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:04 GMT+02:00 Jean-Louis MONTEIRO : >> > It should return at least always a non null principal AFAIR, isn't it? >> > >> > >> > 2014-08-04 19:33 GMT+02:00 Mark Struberg : >> > >> >> 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] >> >> >> http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityListener.java >> >> >> > >> > >> > >> > -- >> > Jean-Louis >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> >> > > >-- >Jean-Louis > > >
Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54
has nothing to do with recycle. Seems that the authentication in BasicAuthenticator only gets triggered in StandardHostValve#171 by calling context.getPipeline().getFirst().invoke(request, response); While the request listener already get triggered in StandardHostValve#167 by calling context.fireRequestInitEvent(request) I've now moved the OWB security stuff from a Listener to a Filter with ordering before=others Works for me, but still wonder what the spec wording defines. LieGrue, strub On Monday, 4 August 2014, 22:56, Romain Manni-Bucau wrote: > > >Hmm > >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 : >> yea exactly. But the user IS authenticated! >> And later in the Filter getUserPrincipal() returns the correct Principal. >> But in the ServletRequestListener (invoked in the same request of course) it >> is null. >> Either it should always be null, or never! >> >> LieGrue, >> strub >> >> >> On Monday, 4 August 2014, 22:12, Jean-Louis MONTEIRO >> wrote: >> >> >>> >>> >>>oups thanks Romain >>> >>> >>>2014-08-04 22:09 GMT+02:00 Romain Manni-Bucau : >>> >>>> "Returns a java.security.Principal object containing the name of the >>>> current authenticated user. If the user has not been authenticated, >>>> the method returns null." >>>> >>>> >>>> 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:04 GMT+02:00 Jean-Louis MONTEIRO : >>>> > It should return at least always a non null principal AFAIR, isn't it? >>>> > >>>> > >>>> > 2014-08-04 19:33 GMT+02:00 Mark Struberg : >>>> > >>>> >> 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] >>>> >> >>>> http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityListener.java >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Jean-Louis >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>> >>>> >>>> >>> >>> >>>-- >>>Jean-Louis >>> >>> >>> > >- >To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >For additional commands, e-mail: dev-h...@tomcat.apache.org > > > >
