You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2006/12/04 17:05:18 UTC

tldCache oddities

Hi,

I tested JSF since some people said the listener wasn't being found (the 
said listener is declared in a TLD which is in a JAR). I found it worked 
very well, but the way it is handled is funny because of the serialized 
cache:
- Catalina will cache but will not bother when adding/removing JARs (for 
example, if you have the cardemo example, you realize the JSF JARs are 
not there, and after the first falied run, you add the JARs in 
/WEB-INF/lib or lib; it is not going to work unless tldCache.ser is 
deleted from the work dir; there's a last modified check, but obviously 
it cannot detect this sort of changes, which is going to be the most 
frequent), and could easily give the impression TLDs are not properly 
found and parsed (note: the bahavior is the same with 5.5)
- Jasper will reparse everything anyway, scanning all JARs in the 
process ( :( )

Avoiding scanning and parsing TLDs is of course faster, but I would like 
to removing caching in Catalina (with a flag to enable it explicitly), 
and add a feature where Catalina will pass an ArrayList of JARs 
containing TLDs to Jasper as an attribute like the annotation processor 
(if the attribute is not there, Jasper will rescan everything, so it 
should remain compatible). This should make up for the slowdown to some 
extent. Unfortunately, I cannot find a cool trick to allow caching, but 
if someone has an idea ...

Comments ?

Rémy

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


Re: tldCache oddities

Posted by Remy Maucherat <re...@apache.org>.
Jacob Hookom wrote:
> Was there ever a condition where the listeners wouldn't run?

For example, you can run a webapp, then stop Tomcat, put the JSF JARs in 
/WEB-INF/lib, and the JSF listener will not be run.

Rémy


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


Re: tldCache oddities

Posted by Jacob Hookom <ja...@hookom.net>.
Was there ever a condition where the listeners wouldn't run?

Remy Maucherat wrote:
> Hi,
>
> I tested JSF since some people said the listener wasn't being found 
> (the said listener is declared in a TLD which is in a JAR). I found it 
> worked very well, but the way it is handled is funny because of the 
> serialized cache:
> - Catalina will cache but will not bother when adding/removing JARs 
> (for example, if you have the cardemo example, you realize the JSF 
> JARs are not there, and after the first falied run, you add the JARs 
> in /WEB-INF/lib or lib; it is not going to work unless tldCache.ser is 
> deleted from the work dir; there's a last modified check, but 
> obviously it cannot detect this sort of changes, which is going to be 
> the most frequent), and could easily give the impression TLDs are not 
> properly found and parsed (note: the bahavior is the same with 5.5)
> - Jasper will reparse everything anyway, scanning all JARs in the 
> process ( :( )
>
> Avoiding scanning and parsing TLDs is of course faster, but I would 
> like to removing caching in Catalina (with a flag to enable it 
> explicitly), and add a feature where Catalina will pass an ArrayList 
> of JARs containing TLDs to Jasper as an attribute like the annotation 
> processor (if the attribute is not there, Jasper will rescan 
> everything, so it should remain compatible). This should make up for 
> the slowdown to some extent. Unfortunately, I cannot find a cool trick 
> to allow caching, but if someone has an idea ...
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> 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