Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
- 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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 Shapira Millennium ChemInformatics -Original Message- From: Jan Luehe [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 5:34 PM To: Shapira, Yoav Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs Hi Shapira, so are you giving this proposal a +1, or do you abstain? :) Thanks, Jan Shapira, Yoav wrote: 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 versa. As long as it's well documented, I never have a problem with a performance enhancement ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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, September 22, 2003 3:40 PM To: Tomcat Developers List Subject: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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 an idea of the proposal's benefit. Currently, we're scanning the following global JARs for TLDs (depending on your runtime, there may be even more!), none of which contain any TLDs: /home/luehe/ws/jakarta-tomcat-5/build/common/lib/servlet-api.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/commons-dbcp.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/naming-common.jar /net/koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solsparc/jre/lib/ext/localedata.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/commons-modeler.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/servlets-invoker.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-jk.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/naming-resources.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/servlets-webdav.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/jakarta-regexp-1.2.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/commons-beanutils.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-cluster.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/jkshm.jar /home/luehe/ws/jakarta-tomcat-5/build/common/endorsed/xmlParserAPIs.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/jasper-compiler.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-http11.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/ant.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/naming-factory.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-jni.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/jmx-tools.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-ant.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-i18n-fr.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-jk2.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/commons-logging.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/commons-el.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/jkconfig.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/servlets-default.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-optional.jar /net/koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solsparc/jre/lib/ext/sunjce_provider.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/commons-logging-api.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/naming-java.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina.jar /net/koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solsparc/jre/lib/ext/ldapsec.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-util.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/commons-pool.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/commons-digester.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-i18n-ja.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/catalina-i18n-es.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/tomcat-coyote.jar /net/koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solsparc/lib/tools.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/commons-fileupload-1.0.jar /home/luehe/ws/jakarta-tomcat-5/build/common/endorsed/xercesImpl.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/commons-collections.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/jasper-runtime.jar /net/koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solsparc/jre/lib/ext/dnsns.jar /home/luehe/ws/jakarta-tomcat-5/build/server/lib/servlets-common.jar /home/luehe/ws/jakarta-tomcat-5/build/bin/bootstrap.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/jmx.jar /home/luehe/ws/jakarta-tomcat-5/build/common/lib/jsp-api.jar Notice that we're scanning this list twice: once for context listeners (in TldConfig.java), and again in Jasper's TldLocationsCache for taglibs. Jan Yoav Shapira Millennium ChemInformatics -Original Message- From: Jan Luehe [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 3:40 PM To: Tomcat Developers List Subject: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs 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
RE: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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 versa. As long as it's well documented, I never have a problem with a performance enhancement ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
