- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, September 22, 2003 10:31 PM
Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Jan Luehe wrote:
Currently, any JARs in the classloader
Bill Barker wrote:
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, September 22, 2003 10:31 PM
Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Jan Luehe wrote:
Currently, any JARs
Petr Jiricka wrote:
Has it? I saw some commits in the area of jar scanning, but not this one.
That hasn't been committed yet, indeed.
As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too agree that limiting the number of
Petr Jiricka wrote:
Remy Maucherat wrote:
Yes, there is.
There's a serialization file which is used to avoid rescanning, unless
a JAR is modified.
That's true, but that does not help on the very first start, only on
subsequent restarts. So I see that this proposal will not represent any
Howdy,
I'm -0 leaning towards -1 unless a significant performance benefit is
demonstrated... If this is an optimization that has some effect only the
first time tomcat is started (because then the TLD scan result file is
serialized), then I don't think your patch should be added... ;)
Yoav
Petr,
I haven't committed any changes related to the proposal yet, as I was
waiting for more feedback. The changes I committed in TldConfig.java
were unrelated.
As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too
Currently, any JARs in the classloader delegation chain of a webapp's
classloader are scanned for packaged TLDs. This is convenient, as it
allows a JAR-packaged taglib to be simply dropped in common/lib and
shared by all webapps, rather than requiring each webapp to bundle the
taglib in its own
Howdy,
Seems like too much work/complication for a small gain. How inefficient
is the current mechanism and how much performance would we gain from
your approach?
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED]
Sent: Monday,
Shapira,
Seems like too much work/complication for a small gain. How inefficient
is the current mechanism and how much performance would we gain from
your approach?
What do you mean by too much work? :)
I already have a patch ready to be committed. It's just a few line changes.
Just to give you
Howdy,
What do you mean by too much work? :)
I already have a patch ready to be committed. It's just a few line
changes.
I mean two things:
1 - the work you've done, implementing the patch;
2 - the work to debug/trace user questions about why their TLDs aren't
loading when they should or vice
The proposal is to add a configurable String property (tldJarNames)
on Context, which specifies the comma-separated list of JAR file names
(without any path info) that must be scanned for TLDs.
+1
Amy :-)
-
To unsubscribe,
Amy Roh wrote:
The proposal is to add a configurable String property (tldJarNames)
on Context, which specifies the comma-separated list of JAR file names
(without any path info) that must be scanned for TLDs.
+1
Amy :-)
Yeah! Thanks! :)
Jan
Jan Luehe wrote:
Currently, any JARs in the classloader delegation chain of a webapp's
classloader are scanned for packaged TLDs. This is convenient, as it
allows a JAR-packaged taglib to be simply dropped in common/lib and
shared by all webapps, rather than requiring each webapp to bundle the
13 matches
Mail list logo
