cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[costin]

costin  2005/09/29 07:36:25

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  Busted by the tab police, fixed the settings.
  
  Revision  ChangesPath
  1.10  +4 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
  
  Index: CatalinaProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- CatalinaProperties.java   29 Sep 2005 05:52:47 -  1.9
  +++ CatalinaProperties.java   29 Sep 2005 14:36:25 -  1.10
  @@ -126,12 +126,12 @@
   if ((is == null) || (error != null)) {
   // Do something
   log.warn("Failed to load catalina.properties", error);
  - // That's fine - we have reasonable defaults.
  - properties=new Properties();
  +// That's fine - we have reasonable defaults.
  +properties=new Properties();
   }
   
   // Register the properties as system properties
  - Enumeration enumeration = properties.propertyNames();
  +Enumeration enumeration = properties.propertyNames();
   while (enumeration.hasMoreElements()) {
   String name = (String) enumeration.nextElement();
   String value = properties.getProperty(name);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[remm]

remm2004/07/23 15:42:16

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  - enum -> enumeration (JDK 1.5 update).
  
  Revision  ChangesPath
  1.7   +4 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
  
  Index: CatalinaProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CatalinaProperties.java   18 May 2004 16:33:24 -  1.6
  +++ CatalinaProperties.java   23 Jul 2004 22:42:16 -  1.7
  @@ -127,9 +127,9 @@
   }
   
   // Register the properties as system properties
  -Enumeration enum = properties.propertyNames();
  -while (enum.hasMoreElements()) {
  -String name = (String) enum.nextElement();
  +Enumeration enumeration = properties.propertyNames();
  +while (enumeration.hasMoreElements()) {
  +String name = (String) enumeration.nextElement();
   String value = properties.getProperty(name);
   if (value != null) {
   System.setProperty(name, value);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[jfarcand]

jfarcand2004/05/18 09:33:24

  Modified:catalina/src/conf catalina.properties
   catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  Make catalina.properties file configurable from catalina.base as well as 
catalina.home. Sometime catalina.home is write protected so modifying the file was 
impossible.
  
  Revision  ChangesPath
  1.10  +6 -4  jakarta-tomcat-catalina/catalina/src/conf/catalina.properties
  
  Index: catalina.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.properties,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- catalina.properties   26 Sep 2003 19:32:08 -  1.9
  +++ catalina.properties   18 May 2004 16:33:24 -  1.10
  @@ -21,8 +21,9 @@
   #
   # List of comma-separated paths defining the contents of the "common" 
   # classloader. Prefixes should be used to define what is the repository type.
  -# Path may be relative to the CATALINA_HOME path or absolute. If left as blank,
  -# the JVM system loader will be used as Catalina's "common" loader.
  +# Path may be relative to the CATALINA_HOME or CATALINA_BASE path or absolute.
  +# If left as blank,the JVM system loader will be used as Catalina's "common" 
  +# loader.
   # Examples:
   # "foo": Add this folder as a class repository
   # "foo/*.jar": Add all the JARs of the specified folder as class 
  @@ -33,8 +34,9 @@
   #
   # List of comma-separated paths defining the contents of the "server" 
   # classloader. Prefixes should be used to define what is the repository type.
  -# Path may be relative to the CATALINA_HOME path or absolute. If left as blank,
  -# the "common" loader will be used as Catalina's "server" loader.
  +# Path may be relative to the CATALINA_HOME or CATALINA_BASE path or absolute.
  +# If left as blank, the "common" loader will be used as Catalina's "server" 
  +# loader.
   # Examples:
   # "foo": Add this folder as a class repository
   # "foo/*.jar": Add all the JARs of the specified folder as class 
  
  
  
  1.6   +10 -2 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
  
  Index: CatalinaProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CatalinaProperties.java   27 Feb 2004 14:58:48 -  1.5
  +++ CatalinaProperties.java   18 May 2004 16:33:24 -  1.6
  @@ -93,7 +93,7 @@
   
   if (is == null) {
   try {
  -File home = new File(getCatalinaHome());
  +File home = new File(getCatalinaBase());
   File conf = new File(home, "conf");
   File properties = new File(conf, "catalina.properties");
   is = new FileInputStream(properties);
  @@ -145,6 +145,14 @@
   private static String getCatalinaHome() {
   return System.getProperty("catalina.home",
 System.getProperty("user.dir"));
  +}
  +
  +
  +/**
  + * Get the value of the catalina.base environment variable.
  + */
  +private static String getCatalinaBase() {
  +return System.getProperty("catalina.base", getCatalinaHome());
   }
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[remm]

remm2003/11/13 08:37:06

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  - Convinience feature: set as system property everything in that file.
  - This could work well along with the property replacement to be added in
server.xml.
  
  Revision  ChangesPath
  1.4   +15 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
  
  Index: CatalinaProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CatalinaProperties.java   26 Sep 2003 19:31:16 -  1.3
  +++ CatalinaProperties.java   13 Nov 2003 16:37:05 -  1.4
  @@ -68,6 +68,7 @@
   import java.io.FileInputStream;
   import java.io.InputStream;
   import java.net.URL;
  +import java.util.Enumeration;
   import java.util.Properties;
   
   
  @@ -170,6 +171,16 @@
   if ((is == null) || (error != null)) {
   // Do something
   System.out.println("Error");
  +}
  +
  +// Register the properties as system properties
  +Enumeration enum = properties.propertyNames();
  +while (enum.hasMoreElements()) {
  +String name = (String) enum.nextElement();
  +String value = properties.getProperty(name);
  +if (value != null) {
  +System.setProperty(name, value);
  +}
   }
   
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Jan Luehe wrote:

Remy Maucherat wrote:

Jan Luehe wrote:

Remy Maucherat wrote:
OK, in this case, I'll add that part of the patch back in, without 
the CatalinaProperties.setProperty, which I'll keep as a private 
extension for now.
I meant the hardcoded list that you put in TldConfig. I don't think 
CatalinaProperties should contain that kind of configuration options 
(which are meant to configure the Bootstrap class Tomcat standalone 
uses).
Would you agree on a "setNoTldJars" method on TldConfig then, which 
would allow the hard-coded list to be overridden?
I don't see what problems is would cause.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Remy Maucherat wrote:
Jan Luehe wrote:

Remy Maucherat wrote:

As for a solution, I believe your hardcoded list was acceptable, if 
not completely optimal.


OK, in this case, I'll add that part of the patch back in, without the 
CatalinaProperties.setProperty, which I'll keep as a private extension 
for now.


I meant the hardcoded list that you put in TldConfig. I don't think 
CatalinaProperties should contain that kind of configuration options 
(which are meant to configure the Bootstrap class Tomcat standalone uses).
Would you agree on a "setNoTldJars" method on TldConfig then, which 
would allow the hard-coded list to be overridden?

Jan



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Remy Maucherat wrote:
Jan Luehe wrote:

Remy Maucherat wrote:

As for a solution, I believe your hardcoded list was acceptable, if 
not completely optimal.


OK, in this case, I'll add that part of the patch back in, without the 
CatalinaProperties.setProperty, which I'll keep as a private extension 
for now.


I meant the hardcoded list that you put in TldConfig. I don't think 
CatalinaProperties should contain that kind of configuration options 
(which are meant to configure the Bootstrap class Tomcat standalone uses).
Got it.

Jan





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Jan Luehe wrote:
Remy Maucherat wrote:

As for a solution, I believe your hardcoded list was acceptable, if 
not completely optimal.
OK, in this case, I'll add that part of the patch back in, without the 
CatalinaProperties.setProperty, which I'll keep as a private extension 
for now.
I meant the hardcoded list that you put in TldConfig. I don't think 
CatalinaProperties should contain that kind of configuration options 
(which are meant to configure the Bootstrap class Tomcat standalone uses).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Remy Maucherat wrote:

OK, I'll revert my patch (and leave it as a private extension), until 
we have found a better solution that everybody agrees on.


Thanks :)

As for a solution, I believe your hardcoded list was acceptable, if not 
completely optimal.
OK, in this case, I'll add that part of the patch back in, without the 
CatalinaProperties.setProperty, which I'll keep as a private extension 
for now.

We can always revisit this issue at a later point.

I feel like I'm on a bazaar. :)

Thanks, Remy!

Jan



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Jan Luehe wrote:
Remy,
I leave the judgement up to the community.


I'll have to reiterate my -1.
OK, I'll revert my patch (and leave it as a private extension), until we 
have found a better solution that everybody agrees on.
Thanks :)

As for a solution, I believe your hardcoded list was acceptable, if not 
completely optimal.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Remy,

As I mentioned in my private email to you, it may not always be
practical to rely on the list of "noTldJars" configured in
catalina.properties if you bundle Tomcat with your own product. That's
why I added the setProperty method on CatalinaProperties, in order
to be able to override the value in catalina.properties. This allows
the list of "noTldJars" to be determined more accurately at
runtime. The code that is embedding Tomcat would call
CatalinaProperties.setProperty() *before* starting Tomcat.


And is exactly what I wanted to avoid. Again, CatalinaProperties is for 
configuring the bootstrap, not anything else (otherwise, stuff which 
belongs to server.xml will end up here, and it will end up being a huge 
mess).
I agree w/ that.

I leave the judgement up to the community.


I'll have to reiterate my -1.
OK, I'll revert my patch (and leave it as a private extension), until we 
have found a better solution that everybody agrees on.

Jan



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Craig R. McClanahan wrote:
Remy Maucherat wrote:

Jan Luehe wrote:

good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader 
hierachy/depth is different from that in Tomcat?
I honestly don't understand why we're searching parent classloaders 
for TLDs.
So that you can have a single copy of a tag library that is shared 
across all of the webapps in that container -- for example, this is what 
JWSDP does with the JSTL and JavaServer Faces tag libraries.  The most 
important reason that you need to scan the TLDs at startup is that you 
can define library-specific listeners in the TLD that become 
automatically installed, without having to touch web.xml.
However, the specification requires that JARs in /WEB-INF/lib are 
scanned. It doesn't say anything about shared JARs, which would hint 
that, in this situation, TLDs should be in /WEB-INF. Furthermore, 
defining application level listeners and stuff like that in a shared 
component seems weird to me.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Jan Luehe wrote:

Remy,

sorry, but I don't see which part of our email exchange you found
"very frustrating". As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
I've done some measurements on my Ultra 60. TldConfig already
calculates the tldScanTime for each context, so that's the number I'm
using. Following are the tldScanTime numbers for a sequence of 10
startups with the "standard" contexts:
- w/o optimization (static initializer in TldConfig commented out):

Context name   tldScanTime for 10 runs   | 
Average
--- 

/manager   417/452/431/438/408/468/434/418/423/450   | 
433.90
/admin 1399/1310/1440/1385/1288/1347/1345/1340/1280/1317 
|1345.10
/servlets-examples 210/198/206/235/192/182/189/188/166/195   | 
196.10
[] 222/222/213/218/222/225/215/204/223/221   | 
218.50
/jsp-examples  996/841/854/862/900/855/903/845/856/815   | 
872.70
/tomcat-docs   155/176/168/184/175/294/164/185/194/183   | 
187.80

Total=3254.10

- With optimization

Context name   tldScanTime for 10 runs   | 
Average
--- 

/manager   239/225/242/375/230/241/234/228/237/319   | 
257.00
/admin 1225/1192/1242/1171/1320/1251/1248/1270/1253/1219 
|1239.10
/servlets-examples 74/69/165/79/92/71/106/96/95/123  | 
97.00
[] 129/109/136/186/241/194/111/103/96/142| 
144.70
/jsp-examples  728/736/757/843/812/796/782/753/820/813   | 
784.00
/tomcat-docs   77/60/127/191/102/101/61/96/88/85 | 
98.80

Total=2620.60
I'm not going to comment on how slow an Ultra 60 is ;-)
You did disable caching for those tests, right ? If you didn't, those 
results are weird.

My comments are:
- Real world apps are not really helped by your optimizations (the admin 
webapp)
- On my Pentium M, the difference is probably not measurable
- This is .8s of the first startup, right ?

This may not be significant, but if you increase the number of
contexts and have additional JARs on your classpath of which you know
they don't contain any TLDs, we're talking seconds, not ms.
And overall, likely less than 5% of the overall startup time, assuming 
real webapps. And, again, that's only for the first startup.

Look, there's still likely useful optimizations to be done in Tomcat 5. 
For example, you can see the buffering which I added, based on the 
analysis of Steve Appling, and which significantly reduces the I/O 
activity in many cases. In this example, the benches are identical, but 
in the real world, it should be a big difference.

However, we should never do useless optimizations, as it always 
increases complexity.

As I mentioned in my private email to you, it may not always be
practical to rely on the list of "noTldJars" configured in
catalina.properties if you bundle Tomcat with your own product. That's
why I added the setProperty method on CatalinaProperties, in order
to be able to override the value in catalina.properties. This allows
the list of "noTldJars" to be determined more accurately at
runtime. The code that is embedding Tomcat would call
CatalinaProperties.setProperty() *before* starting Tomcat.
And is exactly what I wanted to avoid. Again, CatalinaProperties is for 
configuring the bootstrap, not anything else (otherwise, stuff which 
belongs to server.xml will end up here, and it will end up being a huge 
mess).

I leave the judgement up to the community.
I'll have to reiterate my -1.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Hans Bergsten wrote:
Jan Luehe wrote:

I think it depends on whether you anticipate (or support) 
LiteWebServer being bundled (as one or more libraries) into other 
products that use a different directory layout, with different 
locations for shared libs. If that's the case, limiting the location 
of shared libs to $CATALINA_HOME/shared/lib might be too restrictive.
Your milage may wary, but no one embedding LiteWebServer (LWS) today has
complained.
Of course nobody did ;-)
I have yet to see a webapp which doesn't have very visible TLDs, and 
when it doesn't, I don't think it would rely on possibly shared JARs 
which would contain the said TLDs.
This is clearly from the non-portable department.

I think sometimes too much flexibility is what makes a product hard to
use. With LWS, I've stripped down Tomcat to the bare minimum and removed
a lot of choices, and people seem to like how simple things get this
way.
Obviously, useless choices should be removed.

Here, I'm ok with refining the feature a little bit (although it is 
probably not useful), but definitely not adding additional configuration 
options to it.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Hans Bergsten]

Jan Luehe wrote:
Hans,

good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader 
hierachy/depth is different from that in Tomcat?


I don't give them that option (with regards to this) in LiteWebServer.
The only place I look for shared libraries is $CATALINA_HOME/shared/lib.
Is that really a severe limitation, you think?
I think it depends on whether you anticipate (or support) LiteWebServer 
being bundled (as one or more libraries) into other products that use a 
different directory layout, with different locations for shared libs. If 
that's the case, limiting the location of shared libs to 
$CATALINA_HOME/shared/lib might be too restrictive.
Your milage may wary, but no one embedding LiteWebServer (LWS) today has
complained.
I think sometimes too much flexibility is what makes a product hard to
use. With LWS, I've stripped down Tomcat to the bare minimum and removed
a lot of choices, and people seem to like how simple things get this
way.
That's why Tomcat searches the webapp's classloader delegation chain for 
JARs, which ensures that it will find shared libs regardless of their 
location. Of course, by searching the classloader chain all the way up, 
we end up parsing too many JARs. I think it's impossible to know ahead 
of time where to stop in the chain, until you've actually traversed the 
entire chain. For example, an approach that walks the chain just two 
levels up won't work in environments where the classloaders 3 or 4 
levels up in the chain are also responsible for loading shared libs.
Sure, if you can't restrict installation of shared tag libraries to
a directory with a well-known name (off some configurable base, like
CATALINA_HOME), you have no choice but to walk the chain. It's up to
you to decide if it's worth it or not. I'm just piping in with an
alternative that works fine for me and my users.
Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Hans,

good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader hierachy/depth 
is different from that in Tomcat?


I don't give them that option (with regards to this) in LiteWebServer.
The only place I look for shared libraries is $CATALINA_HOME/shared/lib.
Is that really a severe limitation, you think?
I think it depends on whether you anticipate (or support) LiteWebServer 
being bundled (as one or more libraries) into other products that use a 
different directory layout, with different locations for shared libs. If 
that's the case, limiting the location of shared libs to 
$CATALINA_HOME/shared/lib might be too restrictive.

That's why Tomcat searches the webapp's classloader delegation chain for 
JARs, which ensures that it will find shared libs regardless of their 
location. Of course, by searching the classloader chain all the way up, 
we end up parsing too many JARs. I think it's impossible to know ahead 
of time where to stop in the chain, until you've actually traversed the 
entire chain. For example, an approach that walks the chain just two 
levels up won't work in environments where the classloaders 3 or 4 
levels up in the chain are also responsible for loading shared libs.

Jan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Hans Bergsten]

Jan Luehe wrote:
Hans,

thanks for stepping in.

sorry, but I don't see which part of our email exchange you found
"very frustrating". As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
[...]


Sorry for not jumping in earlier in this discussion.

When I implemented the "shared tag libraries" feature in LiteWebServer,
I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR
files in common/lib and server/lib, because placing shared tag libraries
there would be point-less; the container doesn't need access to them,
only the applications do, which is what shared/lib is for.
Maybe that cuts down the list enough so you don't have to mess with
an exclusion list at all?


good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader hierachy/depth 
is different from that in Tomcat?
I don't give them that option (with regards to this) in LiteWebServer.
The only place I look for shared libraries is $CATALINA_HOME/shared/lib.
Is that really a severe limitation, you think?
Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Craig R. McClanahan]

Remy Maucherat wrote:

Jan Luehe wrote:

good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader 
hierachy/depth is different from that in Tomcat?


I honestly don't understand why we're searching parent classloaders 
for TLDs.
So that you can have a single copy of a tag library that is shared 
across all of the webapps in that container -- for example, this is what 
JWSDP does with the JSTL and JavaServer Faces tag libraries.  The most 
important reason that you need to scan the TLDs at startup is that you 
can define library-specific listeners in the TLD that become 
automatically installed, without having to touch web.xml.

Remy 
Craig



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

Jan Luehe wrote:
good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader hierachy/depth 
is different from that in Tomcat?
I honestly don't understand why we're searching parent classloaders for 
TLDs.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Hans,

thanks for stepping in.

sorry, but I don't see which part of our email exchange you found
"very frustrating". As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
[...]


Sorry for not jumping in earlier in this discussion.

When I implemented the "shared tag libraries" feature in LiteWebServer,
I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR
files in common/lib and server/lib, because placing shared tag libraries
there would be point-less; the container doesn't need access to them,
only the applications do, which is what shared/lib is for.
Maybe that cuts down the list enough so you don't have to mess with
an exclusion list at all?
good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader hierachy/depth 
is different from that in Tomcat?

Jan


Hans


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Hans Bergsten]

Jan Luehe wrote:
Remy,

sorry, but I don't see which part of our email exchange you found
"very frustrating". As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
[...]
Sorry for not jumping in earlier in this discussion.

When I implemented the "shared tag libraries" feature in LiteWebServer,
I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR
files in common/lib and server/lib, because placing shared tag libraries
there would be point-less; the container doesn't need access to them,
only the applications do, which is what shared/lib is for.
Maybe that cuts down the list enough so you don't have to mess with
an exclusion list at all?
Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Jan Luehe]

Remy,

sorry, but I don't see which part of our email exchange you found
"very frustrating". As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
I've done some measurements on my Ultra 60. TldConfig already
calculates the tldScanTime for each context, so that's the number I'm
using. Following are the tldScanTime numbers for a sequence of 10
startups with the "standard" contexts:
- w/o optimization (static initializer in TldConfig commented out):

Context name   tldScanTime for 10 runs   | 
Average
---
/manager   417/452/431/438/408/468/434/418/423/450   | 
433.90
/admin 1399/1310/1440/1385/1288/1347/1345/1340/1280/1317 
|1345.10
/servlets-examples 210/198/206/235/192/182/189/188/166/195   | 
196.10
[] 222/222/213/218/222/225/215/204/223/221   | 
218.50
/jsp-examples  996/841/854/862/900/855/903/845/856/815   | 
872.70
/tomcat-docs   155/176/168/184/175/294/164/185/194/183   | 
187.80

Total=3254.10

- With optimization

Context name   tldScanTime for 10 runs   | 
Average
---
/manager   239/225/242/375/230/241/234/228/237/319   | 
257.00
/admin 1225/1192/1242/1171/1320/1251/1248/1270/1253/1219 
|1239.10
/servlets-examples 74/69/165/79/92/71/106/96/95/123  | 
97.00
[] 129/109/136/186/241/194/111/103/96/142| 
144.70
/jsp-examples  728/736/757/843/812/796/782/753/820/813   | 
784.00
/tomcat-docs   77/60/127/191/102/101/61/96/88/85 | 
98.80

Total=2620.60

This may not be significant, but if you increase the number of
contexts and have additional JARs on your classpath of which you know
they don't contain any TLDs, we're talking seconds, not ms.
As I mentioned in my private email to you, it may not always be
practical to rely on the list of "noTldJars" configured in
catalina.properties if you bundle Tomcat with your own product. That's
why I added the setProperty method on CatalinaProperties, in order
to be able to override the value in catalina.properties. This allows
the list of "noTldJars" to be determined more accurately at
runtime. The code that is embedding Tomcat would call
CatalinaProperties.setProperty() *before* starting Tomcat.
I leave the judgement up to the community.

Thanks,

Jan

Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

luehe   2003/09/24 12:09:29

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  Added setProperty method.
For example, this will allow the value for the "noTldJars" 
property to
  be determined and set dynamically.


After a very frustrating private email exchange ...

As I said previously:

-1 for allowing configuration of a TLD exclusion list, because we're not 
out there to gain .01s on startup time, and a hardcoded list is good 
enough and will give us 99% of the benfit (which is already dubious IMO, 
but I don't mind about it overall). Also, (see below), the place where 
this is configured seems inappropriate.

-1 for allowing dynaminc configuration of CatalinaProperties. 
cataina.properties is only meant to be able to configure the Bootstrap 
class of Tomcat, and shouldn't be a place to hack in things we want to 
hide.

Please consider reverting the relevant patches. I think the best would 
be to completely remove the TLD exclusion list feature, as adding 
gratuitous complexity is bad.

Thanks :)

Remy



-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
luehe   2003/09/24 12:09:29

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  Added setProperty method.
  
  For example, this will allow the value for the "noTldJars" property to
  be determined and set dynamically.
After a very frustrating private email exchange ...

As I said previously:

-1 for allowing configuration of a TLD exclusion list, because we're not 
out there to gain .01s on startup time, and a hardcoded list is good 
enough and will give us 99% of the benfit (which is already dubious IMO, 
but I don't mind about it overall). Also, (see below), the place where 
this is configured seems inappropriate.

-1 for allowing dynaminc configuration of CatalinaProperties. 
cataina.properties is only meant to be able to configure the Bootstrap 
class of Tomcat, and shouldn't be a place to hack in things we want to hide.

Please consider reverting the relevant patches. I think the best would 
be to completely remove the TLD exclusion list feature, as adding 
gratuitous complexity is bad.

Thanks :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java

[luehe]

luehe   2003/09/24 12:09:29

  Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
  Log:
  Added setProperty method.
  
  For example, this will allow the value for the "noTldJars" property to
  be determined and set dynamically.
  
  Revision  ChangesPath
  1.2   +17 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
  
  Index: CatalinaProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CatalinaProperties.java   24 Oct 2002 13:53:22 -  1.1
  +++ CatalinaProperties.java   24 Sep 2003 19:09:29 -  1.2
  @@ -117,6 +117,19 @@
   }
   
   
  +/**
  + * Sets the property with the specified key to the specified value.
  + *
  + * @param key the property key
  + * @param value the property value
  + * @return the previous value of the specified key in the property
  + * list, or null if it did not have one.
  + */
  +public static Object setProperty(String key, String value) {
  +return properties.setProperty(key, value);
  +}
  +
  +
   // - Public Methods
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]