You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Amy Roh <am...@apache.org> on 2003/09/19 21:42:10 UTC
Manager deploy when unpackWARs = false
Deployed webapps don't survive restart if Host unpackWARs is set to false.
Is this expected behavior?
Thanks,
Amy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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
> performance improvement on second and subsequent starts. I still think
> we should look for a way to improve the first start time.
Thanks for confirming what I was suspecting. I strongly disagree with
that kind of optimizations unless it has zero useability impact. Since
it can cause usert errors, I am changing my vote to a -1.
>> I think this is good enough, and hence my -0 (I'm leaning towards -1
>> now, as this could indeed be misused; I'd like to see some performance
>> improvement before changing my vote).
>
> What I don't like about Jan's proposal is the need for user
> configuration. But what's wrong with having a list of well known jar
> files and skipping those?
OTOH, I'm ok with adding a list of JARs known not to have a TLD.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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
> performance improvement on second and subsequent starts. I still think
> we should look for a way to improve the first start time.
Thanks for confirming what I was suspecting. I strongly disagree with
that kind of optimizations unless it has zero useability impact. Since
it can cause usert errors, I am changing my vote to a -1.
>> I think this is good enough, and hence my -0 (I'm leaning towards -1
>> now, as this could indeed be misused; I'd like to see some performance
>> improvement before changing my vote).
>
> What I don't like about Jan's proposal is the need for user
> configuration. But what's wrong with having a list of well known jar
> files and skipping those?
OTOH, I'm ok with adding a list of JARs known not to have a TLD.
Remy
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Petr Jiricka <pe...@sun.com>.
Remy Maucherat wrote:
> 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 jars scanned could
>> substantially improve first start performance, however I am worried
>> that the solution as suggested by Jan will make it too easy for the
>> users to shoot themselves to the foot. Also, unless the user does
>> some manual setup, there will be no performance gain,right? So
>> wouldn't it be better to have a hardcoded list of well-known jar
>> files that should be excluded from scanning? This would include all
>> jars found in the Tomcat installation.
>>
>> I also think that under no circumstances the jar files in WEB-INF/lib
>> should be excluded from scanning, as that is in conflict with the spec.
>>
>> Or is there something I am missing about the proposal?
>
>
> 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
performance improvement on second and subsequent starts. I still think
we should look for a way to improve the first start time.
>
>
> I think this is good enough, and hence my -0 (I'm leaning towards -1
> now, as this could indeed be misused; I'd like to see some performance
> improvement before changing my vote).
What I don't like about Jan's proposal is the need for user
configuration. But what's wrong with having a list of well known jar
files and skipping those?
Petr
>
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Petr Jiricka <pe...@sun.com>.
Remy Maucherat wrote:
> 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 jars scanned could
>> substantially improve first start performance, however I am worried
>> that the solution as suggested by Jan will make it too easy for the
>> users to shoot themselves to the foot. Also, unless the user does
>> some manual setup, there will be no performance gain,right? So
>> wouldn't it be better to have a hardcoded list of well-known jar
>> files that should be excluded from scanning? This would include all
>> jars found in the Tomcat installation.
>>
>> I also think that under no circumstances the jar files in WEB-INF/lib
>> should be excluded from scanning, as that is in conflict with the spec.
>>
>> Or is there something I am missing about the proposal?
>
>
> 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
performance improvement on second and subsequent starts. I still think
we should look for a way to improve the first start time.
>
>
> I think this is good enough, and hence my -0 (I'm leaning towards -1
> now, as this could indeed be misused; I'd like to see some performance
> improvement before changing my vote).
What I don't like about Jan's proposal is the need for user
configuration. But what's wrong with having a list of well known jar
files and skipping those?
Petr
>
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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 jars scanned could substantially
> improve first start performance, however I am worried that the solution
> as suggested by Jan will make it too easy for the users to shoot
> themselves to the foot. Also, unless the user does some manual setup,
> there will be no performance gain,right? So wouldn't it be better to
> have a hardcoded list of well-known jar files that should be excluded
> from scanning? This would include all jars found in the Tomcat
> installation.
>
> I also think that under no circumstances the jar files in WEB-INF/lib
> should be excluded from scanning, as that is in conflict with the spec.
>
> Or is there something I am missing about the proposal?
Yes, there is.
There's a serialization file which is used to avoid rescanning, unless a
JAR is modified.
I think this is good enough, and hence my -0 (I'm leaning towards -1
now, as this could indeed be misused; I'd like to see some performance
improvement before changing my vote).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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 jars scanned could substantially
> improve first start performance, however I am worried that the solution
> as suggested by Jan will make it too easy for the users to shoot
> themselves to the foot. Also, unless the user does some manual setup,
> there will be no performance gain,right? So wouldn't it be better to
> have a hardcoded list of well-known jar files that should be excluded
> from scanning? This would include all jars found in the Tomcat
> installation.
>
> I also think that under no circumstances the jar files in WEB-INF/lib
> should be excluded from scanning, as that is in conflict with the spec.
>
> Or is there something I am missing about the proposal?
Yes, there is.
There's a serialization file which is used to avoid rescanning, unless a
JAR is modified.
I think this is good enough, and hence my -0 (I'm leaning towards -1
now, as this could indeed be misused; I'd like to see some performance
improvement before changing my vote).
Remy
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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 agree that limiting the number of jars scanned could substantially
> improve first start performance, however I am worried that the solution
> as suggested by Jan will make it too easy for the users to shoot
> themselves to the foot.
Actually, if they don't do anything, things will continue to work, as by
default the container would continue to scan all globally shared JARs.
If they knew their webapp relied on just jstl.jar, they would configure
the property with just that name.
> Also, unless the user does some manual setup,
> there will be no performance gain,right? So wouldn't it be better to
> have a hardcoded list of well-known jar files that should be excluded
> from scanning? This would include all jars found in the Tomcat
> installation.
OK, I like that idea.
> I also think that under no circumstances the jar files in WEB-INF/lib
> should be excluded from scanning, as that is in conflict with the spec.
That was never part of the proposal, the proposal only dealt with
globally shared JARs, which represent a Tomcat-specific extension to the
spec.
Thanks,
Jan
> Or is there something I am missing about the proposal?
>
> Petr
>
>>
>>
>>
>>> Remy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> This message is intended only for the use of the person(s) listed
>> above as the intended recipient(s), and may contain information that
>> is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
>> you may not read, copy, or distribute this message or any attachment.
>> If you received this communication in error, please notify us
>> immediately by e-mail and then delete all copies of this message and
>> any attachments.
>>
>> In addition you should be aware that ordinary (unencrypted) e-mail
>> sent through the Internet is not secure. Do not send confidential or
>> sensitive information, such as social security numbers, account
>> numbers, personal identification numbers and passwords, to us via
>> ordinary (unencrypted) e-mail.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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 agree that limiting the number of jars scanned could substantially
> improve first start performance, however I am worried that the solution
> as suggested by Jan will make it too easy for the users to shoot
> themselves to the foot.
Actually, if they don't do anything, things will continue to work, as by
default the container would continue to scan all globally shared JARs.
If they knew their webapp relied on just jstl.jar, they would configure
the property with just that name.
> Also, unless the user does some manual setup,
> there will be no performance gain,right? So wouldn't it be better to
> have a hardcoded list of well-known jar files that should be excluded
> from scanning? This would include all jars found in the Tomcat
> installation.
OK, I like that idea.
> I also think that under no circumstances the jar files in WEB-INF/lib
> should be excluded from scanning, as that is in conflict with the spec.
That was never part of the proposal, the proposal only dealt with
globally shared JARs, which represent a Tomcat-specific extension to the
spec.
Thanks,
Jan
> Or is there something I am missing about the proposal?
>
> Petr
>
>>
>>
>>
>>> Remy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> This message is intended only for the use of the person(s) listed
>> above as the intended recipient(s), and may contain information that
>> is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
>> you may not read, copy, or distribute this message or any attachment.
>> If you received this communication in error, please notify us
>> immediately by e-mail and then delete all copies of this message and
>> any attachments.
>>
>> In addition you should be aware that ordinary (unencrypted) e-mail
>> sent through the Internet is not secure. Do not send confidential or
>> sensitive information, such as social security numbers, account
>> numbers, personal identification numbers and passwords, to us via
>> ordinary (unencrypted) e-mail.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Petr Jiricka <pe...@sun.com>.
Bill Barker wrote:
>----- Original Message -----
>From: "Remy Maucherat" <re...@apache.org>
>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>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 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 WEB-INF/lib.
>>>
>>>However, scanning all available JARs for TLDs is not very efficient,
>>>especially if the names of the JAR-packaged taglibs are known in
>>>advance.
>>>
>>>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.
>>>
>>>Catalina will continue to traverse the classloader delegation chain,
>>>but only consider those JARs that match the names in the
>>>comma-separated list.
>>>
>>>If a JAR appears more than once in the classloader delegation chain,
>>>we will pick its first occurrence.
>>>
>>>If the "tldJarNames" property is not set, Catalina will continue to scan
>>> all JARs in the classloader delegation chain for TLDs.
>>>
>>>Comments?
>>>
>>>
>>Same as Yoav. -0. much pain, no gain.
>>
>>
>
>Seeing as how it's already been committed, +0.
>
Has it? I saw some commits in the area of jar scanning, but not this one.
>
>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 jars scanned could substantially
improve first start performance, however I am worried that the solution
as suggested by Jan will make it too easy for the users to shoot
themselves to the foot. Also, unless the user does some manual setup,
there will be no performance gain,right? So wouldn't it be better to
have a hardcoded list of well-known jar files that should be excluded
from scanning? This would include all jars found in the Tomcat installation.
I also think that under no circumstances the jar files in WEB-INF/lib
should be excluded from scanning, as that is in conflict with the spec.
Or is there something I am missing about the proposal?
Petr
>
>
>
>>Remy
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>
>------------------------------------------------------------------------
>
>
>This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
>In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> Seeing as how it's already been committed, +0.
>
> As Jan has already pointed out, it should improve the startup time for
> Tomcat 5 (since scanning TLD files is a major hit).
I think this is incorrect. The code used to avoid JAR locking on Windows
(and likely a resource leak on Unix) likely is a bigger performance hit.
-1 for removing it, obviously.
As for TLD scanning, there's the tldCache.ser that Costin is
implemented, and which avoids rescanning (except on the first startup
after installation). Jan's patch is useless, hence my -0 (I assume the
idea to implement this change is not Jan's anyway).
Remy
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Petr Jiricka <pe...@sun.com>.
Bill Barker wrote:
>----- Original Message -----
>From: "Remy Maucherat" <re...@apache.org>
>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>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 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 WEB-INF/lib.
>>>
>>>However, scanning all available JARs for TLDs is not very efficient,
>>>especially if the names of the JAR-packaged taglibs are known in
>>>advance.
>>>
>>>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.
>>>
>>>Catalina will continue to traverse the classloader delegation chain,
>>>but only consider those JARs that match the names in the
>>>comma-separated list.
>>>
>>>If a JAR appears more than once in the classloader delegation chain,
>>>we will pick its first occurrence.
>>>
>>>If the "tldJarNames" property is not set, Catalina will continue to scan
>>> all JARs in the classloader delegation chain for TLDs.
>>>
>>>Comments?
>>>
>>>
>>Same as Yoav. -0. much pain, no gain.
>>
>>
>
>Seeing as how it's already been committed, +0.
>
Has it? I saw some commits in the area of jar scanning, but not this one.
>
>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 jars scanned could substantially
improve first start performance, however I am worried that the solution
as suggested by Jan will make it too easy for the users to shoot
themselves to the foot. Also, unless the user does some manual setup,
there will be no performance gain,right? So wouldn't it be better to
have a hardcoded list of well-known jar files that should be excluded
from scanning? This would include all jars found in the Tomcat installation.
I also think that under no circumstances the jar files in WEB-INF/lib
should be excluded from scanning, as that is in conflict with the spec.
Or is there something I am missing about the proposal?
Petr
>
>
>
>>Remy
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>
>------------------------------------------------------------------------
>
>
>This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
>In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> Seeing as how it's already been committed, +0.
>
> As Jan has already pointed out, it should improve the startup time for
> Tomcat 5 (since scanning TLD files is a major hit).
I think this is incorrect. The code used to avoid JAR locking on Windows
(and likely a resource leak on Unix) likely is a bigger performance hit.
-1 for removing it, obviously.
As for TLD scanning, there's the tldCache.ser that Costin is
implemented, and which avoids rescanning (except on the first startup
after installation). Jan's patch is useless, hence my -0 (I assume the
idea to implement this change is not Jan's anyway).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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 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 WEB-INF/lib.
> >
> > However, scanning all available JARs for TLDs is not very efficient,
> > especially if the names of the JAR-packaged taglibs are known in
> > advance.
> >
> > 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.
> >
> > Catalina will continue to traverse the classloader delegation chain,
> > but only consider those JARs that match the names in the
> > comma-separated list.
> >
> > If a JAR appears more than once in the classloader delegation chain,
> > we will pick its first occurrence.
> >
> > If the "tldJarNames" property is not set, Catalina will continue to scan
> > all JARs in the classloader delegation chain for TLDs.
> >
> > Comments?
>
> Same as Yoav. -0. much pain, no gain.
Seeing as how it's already been committed, +0.
As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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
> taglib in its own WEB-INF/lib.
>
> However, scanning all available JARs for TLDs is not very efficient,
> especially if the names of the JAR-packaged taglibs are known in
> advance.
>
> 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.
>
> Catalina will continue to traverse the classloader delegation chain,
> but only consider those JARs that match the names in the
> comma-separated list.
>
> If a JAR appears more than once in the classloader delegation chain,
> we will pick its first occurrence.
>
> If the "tldJarNames" property is not set, Catalina will continue to scan
> all JARs in the classloader delegation chain for TLDs.
>
> Comments?
Same as Yoav. -0. much pain, no gain.
Remy
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Remy Maucherat <re...@apache.org>.
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
> taglib in its own WEB-INF/lib.
>
> However, scanning all available JARs for TLDs is not very efficient,
> especially if the names of the JAR-packaged taglibs are known in
> advance.
>
> 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.
>
> Catalina will continue to traverse the classloader delegation chain,
> but only consider those JARs that match the names in the
> comma-separated list.
>
> If a JAR appears more than once in the classloader delegation chain,
> we will pick its first occurrence.
>
> If the "tldJarNames" property is not set, Catalina will continue to scan
> all JARs in the classloader delegation chain for TLDs.
>
> Comments?
Same as Yoav. -0. much pain, no gain.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Amy Roh <am...@apache.org>.
> 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, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Amy Roh <am...@apache.org>.
> 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 :-)
[PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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 WEB-INF/lib.
However, scanning all available JARs for TLDs is not very efficient,
especially if the names of the JAR-packaged taglibs are known in
advance.
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.
Catalina will continue to traverse the classloader delegation chain,
but only consider those JARs that match the names in the
comma-separated list.
If a JAR appears more than once in the classloader delegation chain,
we will pick its first occurrence.
If the "tldJarNames" property is not set, Catalina will continue to scan
all JARs in the classloader delegation chain for TLDs.
Comments?
Jan
[PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Posted by Jan Luehe <Ja...@Sun.COM>.
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 WEB-INF/lib.
However, scanning all available JARs for TLDs is not very efficient,
especially if the names of the JAR-packaged taglibs are known in
advance.
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.
Catalina will continue to traverse the classloader delegation chain,
but only consider those JARs that match the names in the
comma-separated list.
If a JAR appears more than once in the classloader delegation chain,
we will pick its first occurrence.
If the "tldJarNames" property is not set, Catalina will continue to scan
all JARs in the classloader delegation chain for TLDs.
Comments?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Remy Maucherat wrote:
>> Fixing the bug is rather annoying, and the amount of stuff which
>> should be automated is quite big, and seems not worth it.
>> Instead, I'd like to remove local deploy from the manager servlet
>> (IMO, it's useless). If using the Ant tasks to do a local deploy, then
>> it's up to you to persist the config later, upon the user's choice.
>
> +0
I can confirm it can't be done automatically, because when deploying
from a configFile, there's no way to know what context is being
deployed. And it wouldn't work anyway as the XML would be saved to the
original config file location.
I'll have to add code in StandardContext to have it move its config file
to the config base if there's one and it's outside the config base.
For the last case, (WAR file + no config file + unpackWAR == false), the
config file will have to be saved automatically after deploying (which
should work, as the context path is known).
>> I think we should also add some Ant tasks:
>> - a "save config" Ant task - with a context parameter allowing to save
>> just one context (this task is also useful when using the JMX tasks to
>> reconfigure Tomcat, and persisting the config is needed)
I've added the new /save mapping and code. Coding the corresponding
action is trivial.
>> - maybe extend a bit the JMX tasks
>
> +1
Remy
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Remy Maucherat wrote:
>> Fixing the bug is rather annoying, and the amount of stuff which
>> should be automated is quite big, and seems not worth it.
>> Instead, I'd like to remove local deploy from the manager servlet
>> (IMO, it's useless). If using the Ant tasks to do a local deploy, then
>> it's up to you to persist the config later, upon the user's choice.
>
> +0
I can confirm it can't be done automatically, because when deploying
from a configFile, there's no way to know what context is being
deployed. And it wouldn't work anyway as the XML would be saved to the
original config file location.
I'll have to add code in StandardContext to have it move its config file
to the config base if there's one and it's outside the config base.
For the last case, (WAR file + no config file + unpackWAR == false), the
config file will have to be saved automatically after deploying (which
should work, as the context path is known).
>> I think we should also add some Ant tasks:
>> - a "save config" Ant task - with a context parameter allowing to save
>> just one context (this task is also useful when using the JMX tasks to
>> reconfigure Tomcat, and persisting the config is needed)
I've added the new /save mapping and code. Coding the corresponding
action is trivial.
>> - maybe extend a bit the JMX tasks
>
> +1
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
Remy Maucherat wrote:
> Amy Roh wrote:
>
>>> Local deploys do not copy the WAR over.
>>
>>
>> So local deploy is *not* persistant until we implement to save
>> config. This
>> is what I was referring to.
>
>
> Fixing the bug is rather annoying, and the amount of stuff which should
> be automated is quite big, and seems not worth it.
> Instead, I'd like to remove local deploy from the manager servlet (IMO,
> it's useless). If using the Ant tasks to do a local deploy, then it's up
> to you to persist the config later, upon the user's choice.
+0
>
> I think we should also add some Ant tasks:
> - a "save config" Ant task - with a context parameter allowing to save
> just one context (this task is also useful when using the JMX tasks to
> reconfigure Tomcat, and persisting the config is needed)
> - maybe extend a bit the JMX tasks
+1
Amy
>
> Comments ?
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
Remy Maucherat wrote:
> Amy Roh wrote:
>
>>> Local deploys do not copy the WAR over.
>>
>>
>> So local deploy is *not* persistant until we implement to save
>> config. This
>> is what I was referring to.
>
>
> Fixing the bug is rather annoying, and the amount of stuff which should
> be automated is quite big, and seems not worth it.
> Instead, I'd like to remove local deploy from the manager servlet (IMO,
> it's useless). If using the Ant tasks to do a local deploy, then it's up
> to you to persist the config later, upon the user's choice.
+0
>
> I think we should also add some Ant tasks:
> - a "save config" Ant task - with a context parameter allowing to save
> just one context (this task is also useful when using the JMX tasks to
> reconfigure Tomcat, and persisting the config is needed)
> - maybe extend a bit the JMX tasks
+1
Amy
>
> Comments ?
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Local deploys do not copy the WAR over.
>
> So local deploy is *not* persistant until we implement to save config. This
> is what I was referring to.
Fixing the bug is rather annoying, and the amount of stuff which should
be automated is quite big, and seems not worth it.
Instead, I'd like to remove local deploy from the manager servlet (IMO,
it's useless). If using the Ant tasks to do a local deploy, then it's up
to you to persist the config later, upon the user's choice.
I think we should also add some Ant tasks:
- a "save config" Ant task - with a context parameter allowing to save
just one context (this task is also useful when using the JMX tasks to
reconfigure Tomcat, and persisting the config is needed)
- maybe extend a bit the JMX tasks
Comments ?
Remy
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Local deploys do not copy the WAR over.
>
> So local deploy is *not* persistant until we implement to save config. This
> is what I was referring to.
Fixing the bug is rather annoying, and the amount of stuff which should
be automated is quite big, and seems not worth it.
Instead, I'd like to remove local deploy from the manager servlet (IMO,
it's useless). If using the Ant tasks to do a local deploy, then it's up
to you to persist the config later, upon the user's choice.
I think we should also add some Ant tasks:
- a "save config" Ant task - with a context parameter allowing to save
just one context (this task is also useful when using the JMX tasks to
reconfigure Tomcat, and persisting the config is needed)
- maybe extend a bit the JMX tasks
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Local deploys do not copy the WAR over.
So local deploy is *not* persistant until we implement to save config. This
is what I was referring to.
> I'm talking about the "Upload a WAR" which will copy the WAR to the
appBase.
I know this one works. :-)
> (please, don't always try to use the only situation which causes trouble)
I'm not. It's your favorite sqe folks. ;-)
> (please vote to my lame ballots)
Okie. X-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Local deploys do not copy the WAR over.
So local deploy is *not* persistant until we implement to save config. This
is what I was referring to.
> I'm talking about the "Upload a WAR" which will copy the WAR to the
appBase.
I know this one works. :-)
> (please, don't always try to use the only situation which causes trouble)
I'm not. It's your favorite sqe folks. ;-)
> (please vote to my lame ballots)
Okie. X-)
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Of course. It corresponds to using the deploy task.
>>After deploying, the WAR should be in the host appBase.
>
>
> I might be on crack again but my WAR doesn't get copied over to the host
> appBase (webapps). If I set unpackWARs to true the war gets unpacked into
> its directory under webapps.
Local deploys do not copy the WAR over. So, as with TC 4.1, you have to
save the config if you want it persisted (the difference with TC 4.1 is
that if unpackWAR is true, then it is also used for webapps deployed
through the manager, which causes the automagic persistence after
restart). There's not much choice here ... Maybe save the context file
(and only that) automatically by using the Server.storeContext thingie
in case of a local deploy (reminder: the save-to-XML needs to be
refactored).
I'm talking about the "Upload a WAR" which will copy the WAR to the appBase.
(please, don't always try to use the only situation which causes trouble)
(please vote to my lame ballots)
Remy
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Of course. It corresponds to using the deploy task.
>>After deploying, the WAR should be in the host appBase.
>
>
> I might be on crack again but my WAR doesn't get copied over to the host
> appBase (webapps). If I set unpackWARs to true the war gets unpacked into
> its directory under webapps.
Local deploys do not copy the WAR over. So, as with TC 4.1, you have to
save the config if you want it persisted (the difference with TC 4.1 is
that if unpackWAR is true, then it is also used for webapps deployed
through the manager, which causes the automagic persistence after
restart). There's not much choice here ... Maybe save the context file
(and only that) automatically by using the Server.storeContext thingie
in case of a local deploy (reminder: the save-to-XML needs to be
refactored).
I'm talking about the "Upload a WAR" which will copy the WAR to the appBase.
(please, don't always try to use the only situation which causes trouble)
(please vote to my lame ballots)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Of course. It corresponds to using the deploy task.
> After deploying, the WAR should be in the host appBase.
I might be on crack again but my WAR doesn't get copied over to the host
appBase (webapps). If I set unpackWARs to true the war gets unpacked into
its directory under webapps.
Amy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Of course. It corresponds to using the deploy task.
> After deploying, the WAR should be in the host appBase.
I might be on crack again but my WAR doesn't get copied over to the host
appBase (webapps). If I set unpackWARs to true the war gets unpacked into
its directory under webapps.
Amy
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Amy Roh wrote:
>>
>>>Deployed webapps don't survive restart if Host unpackWARs is set to
>
> false.
>
>>>Is this expected behavior?
>>
>>It works fine for me.
>
>
> Are you using HTMLManager?
Of course. It corresponds to using the deploy task.
After deploying, the WAR should be in the host appBase.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Amy Roh wrote:
>>
>>>Deployed webapps don't survive restart if Host unpackWARs is set to
>
> false.
>
>>>Is this expected behavior?
>>
>>It works fine for me.
>
>
> Are you using HTMLManager?
Of course. It corresponds to using the deploy task.
After deploying, the WAR should be in the host appBase.
Remy
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Amy Roh wrote:
> > Deployed webapps don't survive restart if Host unpackWARs is set to
false.
> > Is this expected behavior?
>
> It works fine for me.
Are you using HTMLManager?
Amy
>
> If you're using "install" then don't, I've deprecated it (it's been
> confusing people), and "deploy" should be used instead. If you want to
> "save" after an install, then use the admin's commit.
>
> Remy
Re: Manager deploy when unpackWARs = false
Posted by Amy Roh <am...@apache.org>.
> Amy Roh wrote:
> > Deployed webapps don't survive restart if Host unpackWARs is set to
false.
> > Is this expected behavior?
>
> It works fine for me.
Are you using HTMLManager?
Amy
>
> If you're using "install" then don't, I've deprecated it (it's been
> confusing people), and "deploy" should be used instead. If you want to
> "save" after an install, then use the admin's commit.
>
> Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Deployed webapps don't survive restart if Host unpackWARs is set to false.
> Is this expected behavior?
It works fine for me.
If you're using "install" then don't, I've deprecated it (it's been
confusing people), and "deploy" should be used instead. If you want to
"save" after an install, then use the admin's commit.
Remy
Re: Manager deploy when unpackWARs = false
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Deployed webapps don't survive restart if Host unpackWARs is set to false.
> Is this expected behavior?
It works fine for me.
If you're using "install" then don't, I've deprecated it (it's been
confusing people), and "deploy" should be used instead. If you want to
"save" after an install, then use the admin's commit.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org