Hi Mark,
thanks for the clarifications, highly appreciated!
As far as the empty <absolute-ordering/> 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
<absolute-ordering/> 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 <ma...@apache.org>
> To: Tomcat Developers List <dev@tomcat.apache.org>
> 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
