tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: tomcat 7.0.29 startup time
Date Sun, 29 Jul 2012 17:01:16 GMT
Mark Struberg <struberg@yahoo.de> wrote:

>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.

The 'clarification' from the EG is post the last release. I'm pretty sure some code changes
are required. Feel free to open a bz issue so this isn't forgotten.

Mark

>
>LieGrue,
>strub
>
>
>
>----- Original Message -----
>> From: Mark Struberg <struberg@yahoo.de>
>> To: Tomcat Developers List <dev@tomcat.apache.org>
>> 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 <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 <markt@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-unsubscribe@tomcat.apache.org
>>>  For additional commands, e-mail: dev-help@tomcat.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message