Host Manager Question
After one has used the host manager to deploy a new host, how do you force a save of the server.xml so that when Tomcat is re-started the host is still there? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Host Manager Question
I'm really trying to come up with something that is scriptable. I'm also concerned that the saving function seems to force a reload of contexts. I want to do something like: 1) Get an organization name from the user. 2) Create a web application/user name/database automatically. 3) Deploy a virtual host with .mydomain.name, with an alias of "calendar.theirdomain.name" I have automated creation of DNS entries for .mydomain.name. I can also see how to script creation of the virtual host. I'm just down to how to force a save. I guess I need to try looking at the source code for the admin application. I just really hate struts and was hoping there was some simple way of getting it done. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Yoav Shapira > Sent: Sunday, December 04, 2005 1:43 PM > To: Tomcat Developers List > Subject: Re: Host Manager Question > > Hi, > One way that comes to mind is to do anything (at all) in the Admin > webapp, then click its "commit changes" button. This seems like a > workaround, but I've used it in the past anyways because usually after > deploying a new host I need to tweak some of its configuration... > > Yoav > > On 12/4/05, George Sexton <[EMAIL PROTECTED]> wrote: > > After one has used the host manager to deploy a new host, > how do you force a > > save of the server.xml so that when Tomcat is re-started > the host is still > > there? > > > > George Sexton > > MH Software, Inc. > > http://www.mhsoftware.com/ > > Voice: 303 438 9585 > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Yoav Shapira > System Design and Management Fellow > MIT Sloan School of Management > Cambridge, MA, USA > [EMAIL PROTECTED] / www.yoavshapira.com > > - > 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: Host Manager Question
I don't know. I remember the last time I tried to write a patch. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Yoav Shapira > Sent: Sunday, December 04, 2005 2:06 PM > To: Tomcat Developers List > Subject: Re: Host Manager Question > > Hi, > It may be a fairly simple addition to the Manager and/or HostManager > servlets, if someone wanted to write the enhancement patch ;) > > Yoav > > On 12/4/05, George Sexton <[EMAIL PROTECTED]> wrote: > > I'm really trying to come up with something that is > scriptable. I'm also > > concerned that the saving function seems to force a reload > of contexts. > > > > I want to do something like: > > > > 1) Get an organization name from the user. > > > > 2) Create a web application/user name/database automatically. > > > > 3) Deploy a virtual host with .mydomain.name, > with an alias of > > "calendar.theirdomain.name" > > > > I have automated creation of DNS entries for orgname>.mydomain.name. I > > can also see how to script creation of the virtual host. > I'm just down to > > how to force a save. > > > > I guess I need to try looking at the source code for the > admin application. > > I just really hate struts and was hoping there was some > simple way of > > getting it done. > > > > > > > > George Sexton > > MH Software, Inc. > > http://www.mhsoftware.com/ > > Voice: 303 438 9585 > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Yoav Shapira > > > Sent: Sunday, December 04, 2005 1:43 PM > > > To: Tomcat Developers List > > > Subject: Re: Host Manager Question > > > > > > Hi, > > > One way that comes to mind is to do anything (at all) in the Admin > > > webapp, then click its "commit changes" button. This seems like a > > > workaround, but I've used it in the past anyways because > usually after > > > deploying a new host I need to tweak some of its configuration... > > > > > > Yoav > > > > > > On 12/4/05, George Sexton <[EMAIL PROTECTED]> wrote: > > > > After one has used the host manager to deploy a new host, > > > how do you force a > > > > save of the server.xml so that when Tomcat is re-started > > > the host is still > > > > there? > > > > > > > > George Sexton > > > > MH Software, Inc. > > > > http://www.mhsoftware.com/ > > > > Voice: 303 438 9585 > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Yoav Shapira > > > System Design and Management Fellow > > > MIT Sloan School of Management > > > Cambridge, MA, USA > > > [EMAIL PROTECTED] / www.yoavshapira.com > > > > > > > - > > > 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] > > > > > > > -- > Yoav Shapira > System Design and Management Fellow > MIT Sloan School of Management > Cambridge, MA, USA > [EMAIL PROTECTED] / www.yoavshapira.com > > - > 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: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
I reported an issue where the file would be truncated if the web application directory is not writable by tomcat. It tries to write a file in the webapps/app/META-INF directory. Could this be your issue? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Yong Gou [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 3:03 AM > To: Tomcat Developers List > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > Hi Peter, > > There were just some info, no severe exception was thrown. > You can try it in your environment. > > Thanks, > Eric > > > -Original Message- > From: Peter Rossbach [mailto:[EMAIL PROTECTED] > Sent: 2006年1月16日 17:39 > To: Tomcat Developers List > Subject: Re: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > Hey, > > see you any exception inside your log? > > Regards > peter > > > Am 16.01.2006 um 09:29 schrieb Yong Gou: > > > The version of Tomcat server is 5.5.12 > > > > -Original Message- > > From: Yong Gou > > Sent: 2006年1月16日 16:24 > > To: dev@tomcat.apache.org > > Subject: truncated server.xml got when storing config on condition > > that more than one vitual host with same application base > directory > > "webapps" were defined. > > > > Hi, > > > > > > > > I am not sure if the following is an issue of Tomcat JMX > server or an > > improper usage? Is there anyone who has experienced the same? > > > > In addition to the virtual host localhost which is predefined by > > Tomcat > > server as the default on a Tomcat server, I created another > virtual > > host > > testvh on the server with its attribute appBase being specified as > > webapps and other attributes having their default values via Tomcat > > admin console webapp, and then clicked the "commit changes" > button to > > save all configurations to the server's server.xml file. The > > operations > > resulted in the following server.xml. > > > > NOTE that the Host, Engine, Service and Server elements are not > > closed. > > This is an incomplete server.xml. However if I specified > another value > > other than webapps for its attribute appBase when the virtual host > > testvh was created, the issue would disappear and I could get a > > correct > > server.xml. You can try to define more virtual hosts with the same > > appBase webapps if two cannot reproduce the issue. > > > > > > > > > > > > > > > port="9005"> > > > >> className="org.apache.catalina.core.AprLifecycleListener"/> > > > >> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycle > Listener > > "/ > >> > > > >> > className="org.apache.catalina.storeconfig.StoreConfigLifecycl > eListene > > r" > > /> > > > >> className="org.apache.catalina.mbeans.ServerLifecycleListener"/> > > > > > > > > > > > name="simpleValue" > > > > type="java.lang.Integer" > > > > value="30"/> > > > > > > > auth="Container" > > > > description="User database that can be updated and saved" > > > > name="UserDatabase" > > > > type="org.apache.catalina.UserDatabase" > > > > pathname="conf/tomcat-users.xml" > > > > > factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> > > > > > > > >> > > name="Catalina"> > > > > > > > port="9080" > > > > redirectPort="9443" > > > > minSpareThreads="25" > > > > connectionTimeout="2" > > > > maxThreads="150" > > > > maxSpareThreads="75" > > > > maxHttpHeaderSize="8192"> > > > > > > > > > > > port="9009" > > > > redirectPort="9443
RE: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
I didn't notice. Did you follow my advice to check write permissions on all of the webapps directories. As reported, if the tomcat user cannot write to each webapp (or at least the webapp/META-INF directory), then creation of the server.xml will fail in the manner you describe. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Yong Gou [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 8:47 PM > To: Tomcat Developers List > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > Hi Peter, > > I downloaded the 5.5.15 beta from Apache Tomcat downloads > page and installed it on my desktop. But I found the same > issue was still there with this version when I used its admin > console webapp to add a new host and store config to the > server.xml. The following is the resultant server.xml. > > > port="6005"> >className="org.apache.catalina.core.AprLifecycleListener"/> >className="org.apache.catalina.mbeans.GlobalResourcesLifecycle > Listener"/> >className="org.apache.catalina.storeconfig.StoreConfigLifecycl > eListener"/> >className="org.apache.catalina.mbeans.ServerLifecycleListener"/> > >name="simpleValue" > type="java.lang.Integer" > value="30"/> >auth="Container" > description="User database that can be updated and saved" > name="UserDatabase" > type="org.apache.catalina.UserDatabase" > pathname="conf/tomcat-users.xml" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> > > name="Catalina"> > port="6080" > redirectPort="6443" > minSpareThreads="25" > connectionTimeout="6" > connectionLinger="-1" > serverSoTimeout="0" > maxSpareThreads="75" > maxThreads="150" > tcpNoDelay="true" > maxHttpHeaderSize="8192"> > > port="6009" > redirectPort="6443" > protocol="AJP/1.3"> > > defaultHost="localhost" > name="Catalina"> > > appBase="webapps" > name="localhost"> > > appBase="webapps" > name="gyvh"> > > > Thanks, > Eric > > > > -Original Message- > From: Peter Rossbach [mailto:[EMAIL PROTECTED] > Sent: 2006年1月16日 18:30 > To: Tomcat Developers List > Subject: Re: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > It storeconfig server.xml saving after add a new host works for me! > > I have tested with current svn head. > > create host with fixed MBean descriptor from MBeanFactory > (Thanks for > this) > and store server.xml with mbean StoreConfig.storeConfig(). > > Regards > Peter > > My saved server.xml looks like this: > > > port="8010" > shutdown="8010"> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycle > Listener"/ > > > className="org.apache.catalina.storeconfig.StoreConfigLifecycl > eListener" > /> > className="org.apache.catalina.mbeans.ServerLifecycleListener"/> > > auth="Container" >description="User database that can be updated and saved" >name="UserDatabase" >type="org.apache.catalina.UserDatabase" >pathname="conf/tomcat-users.xml" >factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> > >name="Catalina"> >URIEncoding="UTF-8" > port="8011" > connectionTimeout="6" > connectionLinger="-1" > serverSoTimeout="0" > maxSpareThreads="10" > maxThreads="25" > tcpNoDelay="true"> > >URIEncoding="UTF-8" > port="8012" > minSpareTh
Security Manager
I tried running 5.5.14 with -security specified and got this error:
Using Security Manager
Listening for transport dt_socket at address: 7100
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
shutdownHooks)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:
427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
My solution was to add:
grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
permission java.security.AllPermission;
};
To the catalina.policy file. Is this correct?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Manager
It also seems to me the policy file should have:
grant codeBase "file:${catalina.base}/shared/-" {
permission java.security.AllPermission;
};
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
>
> I tried running 5.5.14 with -security specified and got this error:
>
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
> shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>
>
> My solution was to add:
>
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
>
> To the catalina.policy file. Is this correct?
>
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>
>
>
> -
> 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: Security Manager
It also seems to me the policy file should have:
grant codeBase "file:${catalina.base}/shared/-" {
permission java.security.AllPermission;
};
And
permission java.util.PropertyPermission "java.io.tmpdir", "read";
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -----Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
>
> I tried running 5.5.14 with -security specified and got this error:
>
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
> shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>
>
> My solution was to add:
>
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
>
> To the catalina.policy file. Is this correct?
>
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>
>
>
> -
> 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: Security Manager
Yet more. It seems by specification (SRV.3.7.1)
grant {
permission java.io.FilePermission "${catalina.base}/temp/-", "read,
write","delete";
permission java.util.PropertyPermission "javax.servlet.context.tempdir",
"read";
};
Really should be set so.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
>
> I tried running 5.5.14 with -security specified and got this error:
>
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
> shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>
>
> My solution was to add:
>
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
>
> To the catalina.policy file. Is this correct?
>
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>
>
>
> -
> 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: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
If you have the tomcat service running as LocalSystem, then there should be no permission issues. Looking through your post again, I think the issue is the same as mine, you're just getting there differently. I think that its failing on the write of the context.xml, as in my case because the other app didn't correctly free the resource (close the file, whatever). The scenario I'm guessing at is: Host A Saves but doesn't close all files Host B tries to save but can't because Host A's files were'nt correctly closed. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Yong Gou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 25, 2006 9:41 PM > To: Tomcat Developers List > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > yes. I checked each webapps/app/META-INF directory, each of > these directory has a lot of backup files named like > context.xml.2005-11-28.19-02-56. These files were created > when Tomcat server was running. and also I think there should > be no write permission related issues since my Tomcat server > was running on Windows XP. so I am not sure if this is same > as your case. > > Thanks, > Eric > > -Original Message- > From: George Sexton [mailto:[EMAIL PROTECTED] > Sent: 2006年1月19日 0:27 > To: 'Tomcat Developers List' > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > I didn't notice. Did you follow my advice to check write > permissions on all of the webapps directories. > > As reported, if the tomcat user cannot write to each webapp > (or at least the webapp/META-INF directory), then creation of > the server.xml will fail in the manner you describe. > > George Sexton > MH Software, Inc. > http://www.mhsoftware.com/ > Voice: 303 438 9585 > > > > -Original Message- > > From: Yong Gou [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 17, 2006 8:47 PM > > To: Tomcat Developers List > > Subject: RE: truncated server.xml got when storing config > on condition > > that more than one vitual host with same application base directory > > "webapps" were defined. > > > > Hi Peter, > > > > I downloaded the 5.5.15 beta from Apache Tomcat downloads page and > > installed it on my desktop. But I found the same issue was > still there > > with this version when I used its admin console webapp to add a new > > host and store config to the server.xml. The following is the > > resultant server.xml. > > > > > port="6005"> > >> className="org.apache.catalina.core.AprLifecycleListener"/> > >> className="org.apache.catalina.mbeans.GlobalResourcesLifecycle > > Listener"/> > >> className="org.apache.catalina.storeconfig.StoreConfigLifecycl > > eListener"/> > >> className="org.apache.catalina.mbeans.ServerLifecycleListener"/> > > > > > name="simpleValue" > > type="java.lang.Integer" > > value="30"/> > > > auth="Container" > > description="User database that can be updated and saved" > > name="UserDatabase" > > type="org.apache.catalina.UserDatabase" > > pathname="conf/tomcat-users.xml" > > > factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> > > > >> name="Catalina"> > > > port="6080" > > redirectPort="6443" > > minSpareThreads="25" > > connectionTimeout="6" > > connectionLinger="-1" > > serverSoTimeout="0" > > maxSpareThreads="75" > > maxThreads="150" > > tcpNoDelay="true" > > maxHttpHeaderSize="8192"> > > > > > port="6009" > > redirectPort="6443" > > protocol="AJP/1.3"> > > > > > defaultHost="localhost" > > name="Catalina"> > >className="org.apache.catalina.realm.UserDatabaseRealm&qu
Manager Application Structure
Can someone help me understand a little bit of the architecture of the Mbeans used by the Manager application? I've found that the following entries on the HTML manager page are always 0. Max processing time: 0 ms Processing time: 0 s Request count: 0 Error count: 0 Bytes received: 0.00 MB Bytes sent: 0.00 MB I'd like to sort this out and see about fixing it. Also, I'd like threads in Keep-Alive state to show the virtual host for the last request (since it's REALLY unlikely that this will change from request to request). If someone could give me a basic understanding of how the Mbeans work, I can take a stab at fixing them. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
Last time I looked it was still unfixed. http://issues.apache.org/bugzilla/show_bug.cgi?id=37781 The only suggestion I have is to vote for it to be fixed. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Yong Gou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 12:19 AM > To: Tomcat Developers List > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > Hi George, > > Has the issue you mentioned been fixed? If it has, how could > I get this fix? > > Thanks, > Eric > > -Original Message- > From: George Sexton [mailto:[EMAIL PROTECTED] > Sent: 2006年1月27日 0:29 > To: 'Tomcat Developers List' > Subject: RE: truncated server.xml got when storing config on > condition that more than one vitual host with same > application base directory "webapps" were defined. > > If you have the tomcat service running as LocalSystem, then > there should be > no permission issues. > > Looking through your post again, I think the issue is the > same as mine, > you're just getting there differently. I think that its > failing on the write > of the context.xml, as in my case because the other app > didn't correctly > free the resource (close the file, whatever). The scenario > I'm guessing at > is: > > Host A Saves but doesn't close all files > Host B tries to save but can't because Host A's files were'nt > correctly > closed. > > > George Sexton > MH Software, Inc. > http://www.mhsoftware.com/ > Voice: 303 438 9585 > > > > -Original Message- > > From: Yong Gou [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 25, 2006 9:41 PM > > To: Tomcat Developers List > > Subject: RE: truncated server.xml got when storing config on > > condition that more than one vitual host with same > > application base directory "webapps" were defined. > > > > yes. I checked each webapps/app/META-INF directory, each of > > these directory has a lot of backup files named like > > context.xml.2005-11-28.19-02-56. These files were created > > when Tomcat server was running. and also I think there should > > be no write permission related issues since my Tomcat server > > was running on Windows XP. so I am not sure if this is same > > as your case. > > > > Thanks, > > Eric > > > > -Original Message- > > From: George Sexton [mailto:[EMAIL PROTECTED] > > Sent: 2006年1月19日 0:27 > > To: 'Tomcat Developers List' > > Subject: RE: truncated server.xml got when storing config on > > condition that more than one vitual host with same > > application base directory "webapps" were defined. > > > > I didn't notice. Did you follow my advice to check write > > permissions on all of the webapps directories. > > > > As reported, if the tomcat user cannot write to each webapp > > (or at least the webapp/META-INF directory), then creation of > > the server.xml will fail in the manner you describe. > > > > George Sexton > > MH Software, Inc. > > http://www.mhsoftware.com/ > > Voice: 303 438 9585 > > > > > > > -Original Message- > > > From: Yong Gou [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, January 17, 2006 8:47 PM > > > To: Tomcat Developers List > > > Subject: RE: truncated server.xml got when storing config > > on condition > > > that more than one vitual host with same application base > directory > > > "webapps" were defined. > > > > > > Hi Peter, > > > > > > I downloaded the 5.5.15 beta from Apache Tomcat downloads > page and > > > installed it on my desktop. But I found the same issue was > > still there > > > with this version when I used its admin console webapp to > add a new > > > host and store config to the server.xml. The following is the > > > resultant server.xml. > > > > > > > > port="6005"> > > >> > className="org.apache.catalina.core.AprLifecycleListener"/> > > >> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycle > > > Listener"/> > > >> > className="org.apache.catalina.storeconfig.StoreConfigLifecycl > > > eListener"/> >
RE: Tomcat is going down.
You need to repost your question on the users list. http://tomcat.apache.org/lists.html#tomcat-users George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Ángel Prieto [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 2:42 AM > To: dev@tomcat.apache.org > Subject: Tomcat is going down. > > Hello, I'm having some problems with apache+tomcat with this > configuration: > Apache 2.0.51 (on Fedora Core 2) > Tomcat 5.0.28 > JDK 1.4.0_04 > Mod_jk connector for FC2. > > > Sometimes system goes down and we don't have any idea what the reason > is. We get this error sometimes: > > 10-feb-2006 10:05:02 org.apache.commons.modeler.Registry > registerComponent > GRAVE: Error registering > server:type=RequestProcessor,worker=jk-9109,name=JkRequest413 > javax.management.InstanceAlreadyExistsException: > server:type=RequestProcessor,worker=jk-9109,name=JkRequest413 > at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) > at > mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) > at > mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl. > java:1002) > at > mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) > at > org.apache.commons.modeler.Registry.registerComponent(Registry > .java:871) > at > org.apache.jk.common.ChannelSocket.registerRequest(ChannelSock > et.java:436) > at > org.apache.jk.common.HandlerRequest.decodeRequest(HandlerReque > st.java:443) > at > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) > at > org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSo > cket.java:675) > > at > org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( > ThreadPool.java:683) > > at java.lang.Thread.run(Thread.java:536) > > Could anyone tell me something about it? > > thank you in advance. > > -- > Angel Prieto > [EMAIL PROTECTED] > SINERGIA TECNOLÓGICA > C/ Almirante Churruca > > 30007 Murcia > TEL. 968 270 624Fax. 968 231 501 > www.sinergiatec.com > __ > > La información incluida en el presente correo electrónico es > CONFIDENCIAL, siendo para el uso exclusivo del destinatario > arriba mencionado. Si usted lee este mensaje y no es el > destinatario señalado, el empleado o el agente responsable de > entregar el mensaje al destinatario, o ha recibido esta > comunicación por error, le informamos que está totalmente > prohibida cualquier divulgación, distribución o reproducción > de esta comunicación, y le rogamos que nos lo notifique, nos > devuelva el mensaje original a la dirección arriba mencionada > y borre el mensaje. Gracias. > __ > > > > - > 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: never say never...
RESOLVED | INVALID George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: Reinhard Moosauer [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 11:09 AM > To: tomcat-dev@jakarta.apache.org > Subject: never say never... > > Hi List, > > please somebody explain: > > every few days, a strange procedure can be seen on this list. > Somebody asks for improvement, suggests a fix or simply wants > to discuss a new > feature. > Few minutes later, there is an answer from somebody, which > tells us to ignore > this subject, because it is not relevant. > > Is this necessary? Ok, sometimes we are too simple-hearted to > understand all > consequences of our suggestions. > But IMHO, a one-line-answer is not going to help. > > Please, replace your "go away", with "I vote against it". > (Even better would be some keywords for the green, so we can > find some more > wisdom.) > > R. > > - > 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: never say never...
> -Original Message- > From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 1:52 PM > To: Tomcat Developers List > Subject: Re: never say never... > > nor the political aspects of open source projects and how they work, This is a topic in which you should actually have a great deal of interest. Tomcat is a brilliant example of a project that has a totally dysfunctional leadership environment. On paper it is a meritocracy. This is great. The trouble is that the committers have power, without any real responsibility. For example, the responsibility to not be abusive towards others. So, committers can pretty much do anything without consequence. Just as a little example, several months ago I submitted a patch. One committer commented that he would -1 it for the "com.sun" imports. There weren't any com.sun imports, and when called on it the committer just gaffed me off. So, this committer just flat out lied (or was mistaken and when corrected denied the original error) about a reason for rejecting something. To be fair, the patch did have other problems that were legitimate issues. However, they should have been presented rather than a fairy tale invention. As far as how to structurally fix the tomcat group, my only feeble suggestion would be to permit "TOMCAT USERS" to recall or fire committers. Perhaps then some of the more egregious abuses would cease. > but the user brings up a good point, with a probable solution, and I > don't see how a non committer response like the one below is > even justified. I was being ironic or sarcastic. I'm really not sure which. As for the part about "non-committer", I just parroted back the #1 committer response to new bugs or requests entered into BugZilla. Often, when a users re-opens these events and asks why, they're re-closed with only "RESOLVED | INVALID". If you don't like it (as I don't), go to the "committers" that do this. It seems to me that perhaps someone could do a little analysis and address the worst offenders. > I'm not intending to start a flame war here, just asking for a little > bit more courtesy. There won't be courtesy until those people who are the worst offenders are punished in some manner, or have their status as committers revoked. After all, why should they behave when there is no consequence? > Think about it, what would the tomcat project be without its users? It would evidently be living in a state of open source purity where quality application design doesn't conflict with stupid people who want to use the software to solve business problems. The developers of the application who already live on a higher plane than the lowly users, without this interference achieve a higher state of consciousness. Perhaps they would even reach Nerdvana > > Filip > > George Sexton wrote: > > RESOLVED | INVALID > > > > George Sexton > > MH Software, Inc. > > http://www.mhsoftware.com/ > > Voice: 303 438 9585 > > George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Mark Thomas [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 4:02 PM > To: Tomcat Developers List > Subject: Re: never say never... > > George Sexton wrote: > Whilst I agree with the general thrust of the arguments made so far in > this thread I do take serious issue with one of your statements. > > > Just as a little example, several months ago I submitted a > patch. One > > committer commented that he would -1 it for the "com.sun" > imports. There > > weren't any com.sun imports, and when called on it the > committer just gaffed > > me off. > This is not an accurate representation of the facts. The thread can be > read here: > http://marc.theaimsgroup.com/?l=tomcat-dev&r=1&s=allowedAliasM > atches&q=b&w=4 > > The commit Bill was referring to is this one: > http://marc.theaimsgroup.com/?l=tomcat-dev&m=111788844800136&w=4 > that includes > +import com.sun.org.apache.bcel.internal.generic.ALOAD; > > Bill did not "gaff you off". He pointed out he was -1 for the commit > on the basis of the import. He also expanded on other areas he had > concerns over. > > So, this committer just flat out lied (or was mistaken and when > > corrected denied the original error) > Accusing someone of lying is a serious allegation and on the basis of > the dev archive clearly not true in this case. I would urge you to > retract your comment. I stand corrected. The referenced import must have been added by Peter Rossbach when he committed it. My submitted code did not have the com.sun import. This is why I didn't think it was there. When the comment was made, I reviewed my submission and didn't see it. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Mark Thomas [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 4:02 PM > To: Tomcat Developers List > Subject: Re: never say never... > > I agree that closing bug reports without an explanation is rarely, if > ever helpful. A few lines explaining why the bug is invalid / won't be > fixed would help enormously. I think everyone is in agreement here. > > That being said, having spent that last couple of years fixing bugs it > is immensely frustrating when having closed a bug report as invalid > (with an explanation and where appropriate a reference to the spec) it > is re-opened with a comment that clearly indicates that the person > re-opening the bug report hasn't bothered to read the previous > comments or the spec. > > There is an argument that goes along the lines of "If the person > creating the bug report can't be bothered to read the spec / do some > basic fault finding / provide enough information to reproduce the > fault / read http://tomcat.apache.org/bugreport.html etc why should I > be bothered to explain things to them?". Whilst I do not agree with > this view personally, I can see how people have reached this point and > I do understand the frustration they feel. Having a cycle of 4-8 iterations where a person asks why its resolved invalid, and a committer re-marks it resolved invalid without comment doesn't seem like it would reduce frustration on the part of the committer. It seems to me they would just get angrier on each iteration. Don't misunderstand me. I'm certainly not saying a committer shouldn't say "This is non-compliant and will not be addresed" or "We comply with the spec, and we will not be expanding the application to meet your specific need". These are legitimate responses. When the specification is involved, it would be nice to reference the relevant part of the specification. When committers use emotionally charged terms with no technical basis, or just reject things out of hand without explanation its not fair. > > There won't be courtesy until those people who are the > worst offenders are > > punished in some manner, or have their status as committers > revoked. After > > all, why should they behave when there is no consequence? > I don't think that punishment is the answer. If you feel someone is > discourteous point it out (privately or publicly - your choice) and > ask them to modify their behaviour. Above all, don't descend to their > level. This is how things should be done there is just one small flaw. Those people who are the worst offenders in this matter are pretty much unaffected by this approach. If people consistently don't respond to that approach (which should be first), then there needs to be some recourse. For example, a popular book recommends this approach to conflict resolution: 1) Approach the person directly. If that doesn't work. 2) Approach the person with others as witnesses to verify what is said. If the person still doesn't respond: 3) Take the person before the community. If the person still doesn't respond. 4) Eject the person from your community and have nothing further to do with them. While your recommendation is sound, and is indeed step 1 as outlined above, by itself it is not enough. There need to be steps to take if the person doesn't respond. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Mark Thomas [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 5:33 PM > To: Tomcat Developers List > Subject: Re: never say never... > > On the subject of fairness, is it fair that someone who is too lazy to > read the spec / read the docs / etc should take up any more of the > community's time than the absolute minimum required to, for example, > mark the bug as INVALID? This isn't a view I advocate but it is one I > understand. > OK, let's throw out the whole fairness thing. How can the Tomcat committers most efficiently, and with the least amount of anger, hate, and discontent handle people who do not put in a reasonable effort to understand things or submit reasonable defect reports. Candidates are: 1) Committer marks it resolved | invalid. Submitter demands to know why. Committer re-marks it RESOLVED | INVALID, ad infinitum until some other committer decides to break the cycle. Nobody's really happy with this. 2) The committer puts in a minimal reason referencing the spec. To make most people happy, a reference to the specific portion of the spec would have to be researched. The user learns nothing, and the committer is answering questions instead of fixing code. 3) The committer marks it resolved | invalid, and sends the user to the ESR paper on "How to ask questions the smart way." Since the committer could save this snippet of text and copy and paste the text, it seems like it wouldn't be hard. This would hopefully educate the user and result in higher quality submissions in the future. If I've missed any solutions I'd be interested in them. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Preston L. Bannister [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 6:22 PM > To: Tomcat Developers List > Subject: Re: never say never... > > A disclaimer here - I used to have committer status (and might still). > > On 2/20/06, George Sexton <[EMAIL PROTECTED]> wrote: > > > > As far as how to structurally fix the tomcat group, my only feeble > > suggestion would be to permit "TOMCAT USERS" to recall or > fire committers. > > Perhaps then some of the more egregious abuses would cease. > > > > This assumes that committers are an practically unlimited > resource, and they Actually I don't make that assumption and I also don't assume that users will randomly fire all committers. I don't think my proposal would induce a shortage. > were issues with your contribution - that also is a good > thing. If the > answer you got seemed a bit too aburpt (and perhaps it was), > then do try to > understand that the other guy may not have the abundance of time to be > optimally diplomatic. > > In other words, please keep trying... > Actually, I've got two other submissions that are not in critical portions of the code: http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 http://issues.apache.org/bugzilla/show_bug.cgi?id=38508 Perhaps they will get picked up. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Mladen Turk [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 4:48 AM > To: Tomcat Developers List > Subject: Re: never say never... > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 > > > > From your bz report: > > > ... > > I think to be compliant with the spec, this must be allowed. > > ... > > Again, I think the spec requires this. > > ... > > > So, why would anyone even spend a single microsecond to look at > the patch if *you* could not guarantee that the patch is > compliant with the specs? I guess this is my mistake, for trying to sound humble. I was trying to be RESPECTFUL. I'll say it PLAINLY. Servlet Specification 2.4 says: SRV.3.7.1 TEMPORARY WORKING DIRECTORYS A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory for each servlet context, and make it available via the javax.servlet.context.tempdir context attribute. This just flat says that it must be there, and it is a working directory, which implies its writable. > > I applaud to your willing to contribute, but if you wish to > do that, and eventually become a member of the elite, you must > follow some rules, and the first one, like in any company is to > respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: >> Don't see the need. If you depend on this, your app is non-portable since >> there is no requirement that javax.servlet.context.tempdir has any relation to >>java.io.tmpdir. In fact, a servlet container is perfectly free to set >> java.io.tmpdir to /dev/null if it wants. >> > Directory specified by java.io.tmpdir (which is what tomcat points >> > javax.servlet.context.tempdir to) is now read, write, delete. Again, I think >> the >> > spec requires this. I was fixing an implementation specific issue. The spec says that the container MUST make temporary working directories available. The IMPLEMENTATION that tomcat uses is to set java.io.tempdir and javax.servlet.context.tempdir So, my making that writable fixes an implementation specific issue for tomcat. I'll say it again in case I wasn't clear. 1) The spec says javax.servlet.context.tempdir must be a working directory 2) TOMCAT sets that value to the value of java.io.tmpdir THEREFORE FOR THE TOMCAT IMPLEMENTATION java.io.tmpdir MUST BE WRITABLE. So, in short. The ELITE should spend a little more time thinking about things instead of just reflexively trashing people. That is respect. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Mladen Turk [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 4:48 AM > To: Tomcat Developers List > Subject: Re: never say never... > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 > > > > From your bz report: > > > ... > > I think to be compliant with the spec, this must be allowed. > > ... > > Again, I think the spec requires this. > > ... > > > So, why would anyone even spend a single microsecond to look at > the patch if *you* could not guarantee that the patch is > compliant with the specs? I guess this is my mistake, for trying to sound humble. I was trying to be RESPECTFUL. I'll say it PLAINLY. Servlet Specification 2.4 says: SRV.3.7.1 TEMPORARY WORKING DIRECTORYS A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory for each servlet context, and make it available via the javax.servlet.context.tempdir context attribute. This just flat says that it must be there, and it is a working directory, which implies its writable. > > I applaud to your willing to contribute, but if you wish to > do that, and eventually become a member of the elite, you must > follow some rules, and the first one, like in any company is to > respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: >> Don't see the need. If you depend on this, your app is non-portable since >> there is no requirement that javax.servlet.context.tempdir has any relation to >>java.io.tmpdir. In fact, a servlet container is perfectly free to set >> java.io.tmpdir to /dev/null if it wants. >> > Directory specified by java.io.tmpdir (which is what tomcat points >> > javax.servlet.context.tempdir to) is now read, write, delete. Again, I think >> the >> > spec requires this. I was fixing an implementation specific issue. The spec says that the container MUST make temporary working directories available. The IMPLEMENTATION that tomcat uses is to set java.io.tempdir and javax.servlet.context.tempdir So, my making that writable fixes an implementation specific issue for tomcat. I'll say it again in case I wasn't clear. 1) The spec says javax.servlet.context.tempdir must be a working directory 2) TOMCAT sets that value to the value of java.io.tmpdir THEREFORE FOR THE TOMCAT IMPLEMENTATION java.io.tmpdir MUST BE WRITABLE. So, in short. The ELITE should spend a little more time thinking about things instead of just reflexively trashing people. That is respect. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
> -Original Message- > From: Martin van den Bemt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 11:24 AM > To: Tomcat Developers List > Subject: Re: never say never... > > You are pretty bad in taking examples. The example I took was specifically chosen because his comments are incorrect. I suppose I could have put his opening comments where he was baiting me but I chose to ignore those. > Bill nicely described > the why nicely in nice words Bill started out his comments by baiting me. Whether it was done nicely or not depends upon which side of the stick you're on. > (don't > know who is right or wrong, I don't care about that) If you don't know what is wrong or right how do you know Bill gave a great answer? It may have been a pleasant answer, but how can an answer be great if its not right? >> ) and your answer to that is quite unapropiate. >> Especially the shouting. Just say you think he is >> wrong, because of xxx and everyone is happy.. Mladen's comments were pretty intemperate as well. They were accusatory and belittling (joining the "Elite" trash). I think most people would be moved to shout at this point. > In short : I think Bill gave a great answer and you didn't > return that favour. No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdir and javax.servlet.context.tempdir are equivalent in implementation in Tomcat, and that to be compliant, Tomcat has to make java.io.tmpdir writable. > > And another thing : I (and others do to I guess) read > bugzilla mails, so no need to copy & paste > that thing to a thread that has nothing to do with the thread > (despite to what you seem to think). > Mladen specifically referenced the issue. I felt it appropriate in my reply to reference the whole context. I re-posted the relevant portions to bugzilla after drafting the message. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
Never mind. This isn't worth the heart-ache and I'm probably wrong about workdir being defined in terms of tempdir. I made this probably wrong assumption by looking at the startup scripts . George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -Original Message- > From: George Sexton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 10:37 AM > To: 'Tomcat Developers List' > Subject: RE: never say never... > > > > > > -Original Message- > > From: Mladen Turk [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 21, 2006 4:48 AM > > To: Tomcat Developers List > > Subject: Re: never say never... > > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 > > > > > > > From your bz report: > > > > > ... > > > I think to be compliant with the spec, this must be allowed. > > > ... > > > Again, I think the spec requires this. > > > ... > > > > > > So, why would anyone even spend a single microsecond to look at > > the patch if *you* could not guarantee that the patch is > > compliant with the specs? > > I guess this is my mistake, for trying to sound humble. I was > trying to be RESPECTFUL. I'll say it PLAINLY. > > Servlet Specification 2.4 says: > > SRV.3.7.1 TEMPORARY WORKING DIRECTORYS > > A temporary storage directory is required for each servlet > context. Servlet > containers must provide a private temporary directory for > each servlet context, and > make it available via the javax.servlet.context.tempdir > context attribute. > > > This just flat says that it must be there, and it is a > working directory, which implies its writable. > > > > > > > I applaud to your willing to contribute, but if you wish to > > do that, and eventually become a member of the elite, you must > > follow some rules, and the first one, like in any company is to > > respect your colleagues. > > Respect is a two way street. When someone like Bill Barker > creates a logic puzzle as blatantly wrong as he did, then > what level of respect is required? > > Specifically, Bill Barker's comments: > > >> Don't see the need. If you depend on this, your app is > non-portable since > >> there is no requirement that javax.servlet.context.tempdir > has any relation to > >>java.io.tmpdir. In fact, a servlet container is perfectly > free to set > >> java.io.tmpdir to /dev/null if it wants. > > >> > Directory specified by java.io.tmpdir (which is what > tomcat points > >> > javax.servlet.context.tempdir to) is now read, write, > delete. Again, I think > >> the > >> > spec requires this. > > I was fixing an implementation specific issue. The spec says > that the container MUST make temporary working directories available. > > The IMPLEMENTATION that tomcat uses is to set java.io.tempdir > and javax.servlet.context.tempdir > > So, my making that writable fixes an implementation specific > issue for tomcat. I'll say it again in case I wasn't clear. > > 1)The spec says javax.servlet.context.tempdir must be a > working directory > 2)TOMCAT sets that value to the value of java.io.tmpdir > > THEREFORE > > FOR THE TOMCAT IMPLEMENTATION > > java.io.tmpdir MUST BE WRITABLE. > > So, in short. The ELITE should spend a little more time > thinking about things instead of just reflexively trashing > people. That is respect. > > George Sexton > MH Software, Inc. > http://www.mhsoftware.com/ > Voice: 303 438 9585 > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Security Policy Error
I'm running Tomcat 5.5.23 under a security manager, and I'm hitting this error on a call to HttpServletRequest.getAttributeNames() I'm only starting to understand security policies, so I would appreciate some insights on what the best way to approach this issue is. If it's a genuine bug, let me know and I'll open a ticket on bugzilla. Servlet.service() for servlet ErrorServlet threw exception java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.core) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.catalina.core.ApplicationHttpRequest.getAttributeNames(ApplicationHttpRequest.java:243) -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Policy Error
I'm really not sure if it's a bug or not. Here's exactly what's
happening. I have an error handler
com.mhsoftware.cdaily.servlet.ErrorServlet.based on a class
com.MHSoftware.servlet.BaseServlet.
The base class has a method called dumpRequest which dumps an
HTTPServletRequestObject to a string for troubleshooting purposes.
When an error is triggered, the Error Servlet gets invoked and this
error happens:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.core)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at
org.apache.catalina.core.ApplicationHttpRequest.getAttributeNames(ApplicationHttpRequest.java:243)
at com.MHSoftware.servlet.BaseServlet.dumpRequest(BaseServlet.java:805)
at
com.mhsoftware.cdaily.servlet.ErrorServlet.doGet(ErrorServlet.java:36)
at
com.mhsoftware.cdaily.servlet.ErrorServlet.doPost(ErrorServlet.java:105)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
MHS.jar which contains BaseServlet is located in
$CATALINA_BASE/shared/lib, while cdaily.jar, which contains ErrorServlet
is located in Application/WEB-INF/classes
I have a policy entry:
// Add files in the shared classloader hierarchy
// as well.
grant codeBase "file:${catalina.base}/shared/-" {
permission java.security.AllPermission;
};
If I create a simple JSP, and call request.setAttribute() followed by
request.getAttributeNames(), things work OK.
So, I'm really uncertain what's exactly going on. I'm kind of thinking
now that it's class loader related.
I have another class that I noticed was doing something similar. I have
a base object in MHS.jar, and in cdaily.jar, I have child classes. For
reflection to work in those child classes, I had to add a policy entry:
grant {
permission java.lang.RuntimePermission
"accessClassInPackage.com.MHSoftware.db.*";
};
Bill Barker wrote:
It pretty obviously a bug. It looks like we need another PA :(.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Yoav Shapira
Sent: Thursday, May 24, 2007 8:34 AM
To: Tomcat Developers List
Subject: Re: Security Policy Error
George,
Did anyone get back to you about this?
I myself don't have much of a clue, as I haven't run Tomcat 5.5.x
Tomcat under a security manager.
Yoav
On 5/21/07, George Sexton <[EMAIL PROTECTED]> wrote:
I'm running Tomcat 5.5.23 under a security manager, and I'm
hitting this
error on a call to HttpServletRequest.getAttributeNames()
I'm only starting to understand security policies, so I
would appreciate
some insights on what the best way to approach this issue is.
If it's a genuine bug, let me know and I'll open a ticket
on bugzilla.
Servlet.service() for servlet ErrorServlet threw exception
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core)
at
java.security.AccessControlContext.checkPermission(AccessContr
olContext.java:264)
at
java.security.AccessController.checkPermission(AccessControlle
r.java:427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.j
ava:1512)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at
org.apache.catalina.core.ApplicationHttpRequest.getAttributeNa
mes(ApplicationHttpRequest.java:243)
--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL: http://www.mhsoftware.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Re: 5.5.24 candidate binaries
It looks OK to me. Filip Hanik - Dev Lists wrote: how is 5.5.24 looking, if no one objects, I'll plan to start a vote on friday Filip Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.24/ will let these sit to mid next week, and then we can take a vote. feedback between now and then is welcome at any time. Filip - 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] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat supporting PHP
PHP is an interpreter, but there is a large library of functions written in Native code that would have to be supported. It's not just writing a byte-code compiler that would convert the PHP to java code, or even a parser that would re-write a PHP page into JSP. It's creating the massively large library of functions. Joe Nathan wrote: PHP is based on interpreter. Instead, pre-compiler as in JSP can improve performance of PHP significantly. Then there will be lots of people switching to Tomcat regards. pankaj narang wrote: Hello I am listening everything silently here but I think Joe is correct -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat supporting PHP
As an exercise, why don't you write a couple of these trivial libraries. Start with the database ones. They should be very easy since there is a database layer on Java, and a database layer on PHP. If you think I'm being sarcastic, you're right. You're trivializing things you don't understand. Joe Nathan wrote: George L. Sexton-2 wrote: It's not just writing a byte-code compiler that would convert the PHP to java code, or even a parser that would re-write a PHP page into JSP. It's creating the massively large library of functions. Isn't it true that most of libs are already in Java packages? Most of them will need just adaptors. Some other legacies, we may scrap! regards. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5 SSL Configuration Documentation Errors
Here are some misc. doc errors for the Tomcat 5.5 SSL topic I noticed: The Connector configuration XML snippet has a semi-colon after secure="true". The Connector configuration XML snippet references minProcessors and maxProcessors. These parameters do not seem to be current parameters for the HTTP connector. They appear to have been deprecated for the AJP connector. It appears they are replaced with minSpareThreads and maxThreads would be the closest matches. debug= is referenced, but not documented in the standard Connector reference. The attribute for "disableUploadTimeout" is the default. Since it's the default, it's kind of redundant. This also applies to clientAuth, and sslProtocol. So, the corrected example would be: <-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.21?
Filip Hanik - Dev Lists wrote: IMHO, it is due, last version was september 30th...! thanks for your opinion :) we'll get the ball rolling. I have a move pending, we are going from Texas to Colorado, so I'll try to squeeze this in there as well Filip You've picked a bad year. We've had 57 inches of snow so far this winter. Where are you moving to? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new 5.5 candidate, please test
I noticed the changelog stops at 5.5.21. Also, I didn't see any mention of http://issues.apache.org/bugzilla/show_bug.cgi?id=40449 Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.22/ Vote on Friday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new 5.5 candidate, please test
I didn't know that. I just looked at the page for changelog.html and it says 5.5.21. Filip Hanik - Dev Lists wrote: George Sexton wrote: I noticed the changelog stops at 5.5.21. 5.5.21 doesn't exist, hence all changelogs from 5.5.21 goes automatically to 5.5.22. Also, I didn't see any mention of http://issues.apache.org/bugzilla/show_bug.cgi?id=40449 That's cause I'm a goober and forgot it. Filip Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.22/ Vote on Friday - 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] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new 5.5 candidate, please test
One other thing. It looks like the changelog entry for 40929 has a mis-spelling. Filip Hanik - Dev Lists wrote: George Sexton wrote: I noticed the changelog stops at 5.5.21. 5.5.21 doesn't exist, hence all changelogs from 5.5.21 goes automatically to 5.5.22. Also, I didn't see any mention of http://issues.apache.org/bugzilla/show_bug.cgi?id=40449 That's cause I'm a goober and forgot it. Filip Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.22/ Vote on Friday - 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] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.22
I've tested it with my app and it seems to work fine. It's got a couple of things in it that I obviously would like to see. I noticed the warning on the malformed parameter list (I had to ampersands together). Filip Hanik - Dev Lists wrote: Jess Holle wrote: Filip Hanik - Dev Lists wrote: Ok folks, for those that want to see the 5.0.22, please provide some feedback. Without votes, I can't push out a release. [I'm sure you meant 5.5.22, not 5.0.22...] Do votes from non-commiters count in this regard, i.e. in a decisive manner as to whether a release is pushed out? The feedback from non-committers is definitely take into account, as more testing proves better for our releases. so this is something we do encourage If so, I can try to make some time to test this out. If not I've got a rather full near term plate -- but am still very interested in having a "stable" 5.5.x release in the somewhat near term. No problem, when you get the time we look forward to your feedback Filip -- Jess Holle Filip Hanik - Dev Lists wrote: Candidate binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.22/ According to the (slightly) updated release process, the 5.5.22 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Filip - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.23
When I try to run 5.5.23 with JDK 1.5.0_08 under windows, I get this error: SEVERE: An incompatible version 0.0.0 of the Apache Tomcat Native library is installed, while Tomcat requires version 1.1.3 Mar 3, 2007 3:43:27 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: An older version 0.0.0 of the Apache Tomcat Native library is installed, while Tomcat recommends version greater than 1.1.4 Is this Tomcat Native thing now required? It wasn't in 5.5.22 (the test build anyhow). Is it normal to change the requirements for how the system operates on a point release? Filip Hanik - Dev Lists wrote: Candidate binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.23/ According to the (slightly) updated release process, the 5.5.23 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Funding someone to fix a few bugs
Is it permitted to offer to fund someone to fix a few bugs? I have three things I'd like to see fixed. One trivial, and two non-trivial. As background, I'm using tomcat to host our web calendar software. I'm currently running some 300+ virtual hosts in one instance of tomcat. I add or remove between 5-8 virtual hosts per day. Because of these defects, new hosts don't have logs until Tomcat is re-started, and removed hosts generate an error when users try to access them. To add and remove the hosts, I'm using custom software that calls the tomcat host-manager application. The bug IDs are: Host Manager Add Host Problems w/ Spaces http://issues.apache.org/bugzilla/show_bug.cgi?id=39125 context.xml not used when new host created. I haven't re-tested this since it's submission. http://issues.apache.org/bugzilla/show_bug.cgi?id=38351 Requests for host removed via Host Manager not sent to Engine Default Host http://issues.apache.org/bugzilla/show_bug.cgi?id=40449 If this is permitted, and anyone is interested, please send me an EMail off-list so we can make arrangements. If this is not permitted, please say so and I will try to come up with some other method of fixing these issues. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Funding someone to fix a few bugs
Yoav Shapira wrote: Hi, George Sexton wrote: > Is it permitted to offer to fund someone to fix a few bugs? I have > three things I'd like to see fixed. One trivial, and two non-trivial. I'm not sure, but I'm not aware of precedents, and I am aware of some discussion against this idea. I really need these things fixed and I really don't have time to try to do it myself. I'm not sure what other recourse I could have other than trying to drum up support from other users. I'm guessing that very few people are doing large scale virtual hosting with Tomcat, so this might not work. As with any patches, you can offer someone $ to come up with a patch, that patch will be submitted, reviewed and if accepted applied to the code base. Yes, the normal patch review and acceptance criteria still apply. Even if you paid someone, a patch can be -1ed or otherwise not make it into the product. I understand how this works... Milestone payments would be made on commit, and release of a stable version incorporating the feature. I'm hoping that since they are genuine defects (IOW, they haven't yet been rejected as INVALID) that a patch of good quality would be accepted. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/dev/urandom usage
I've got a question and it's kind of deep developer question. I was poking around today looking at my tomcat instance running under Linux. I was looking in the /proc//fd directory, which is the list of file descriptors open by my servlet application. There are around 1400 open file descriptors. What I don't understand is why there are some 800+ file descriptors that are open to /dev/urandom. On this particular host there are some 400 configured hosts/contexts. On another server, there are 1100 file descriptors open to /dev/urandom. For this server, there are around 200 configured hosts/contexts. I'm using Sun JDK 1.6.0_14 on OpenSUSE 11.1. One machine is amd64 architecture, while the other is i386. Does anyone have any idea what could be causing this? It seems kind of strange to have 800-1200 file descriptors open to one pseudo file. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: /dev/urandom usage
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Friday, August 14, 2009 5:57 PM > To: Tomcat Developers List > Subject: Re: /dev/urandom usage > > George Sexton wrote: > > I've got a question and it's kind of deep developer question. > > > > I was poking around today looking at my tomcat instance running under > Linux. > > > > I was looking in the /proc//fd directory, which is the list of > file > > descriptors open by my servlet application. > > > > There are around 1400 open file descriptors. What I don't understand > is why > > there are some 800+ file descriptors that are open to /dev/urandom. > On this > > particular host there are some 400 configured hosts/contexts. > > > > On another server, there are 1100 file descriptors open to > /dev/urandom. For > > this server, there are around 200 configured hosts/contexts. > > > > I'm using Sun JDK 1.6.0_14 on OpenSUSE 11.1. One machine is amd64 > > architecture, while the other is i386. > > > > Does anyone have any idea what could be causing this? It seems kind > of > > strange to have 800-1200 file descriptors open to one pseudo file. > > Take a look at ManagerBase.getRandom(). The probably explains the > majority of it. > > Mark H. You'll have to execuse me if this is a dumb question, but does that mean that each session is creating its own instance of java.security.SecureRandom, and each instance of java.security.SecureRandom is opening /dev/urandom? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: /dev/urandom usage
OK, I looked at this some more.
What's really happening is ManagerBase is using /dev/urandom if it exists in
getRandomBytes(). getRandom() is just a fallback if devRandomSource
(/dev/urandom) doesn't exist.
>From digging deeper, it looks like StandardContext instantiates a copy of
StandardManager(). So, every context is opening the file.
Looking at StandardManager.stop() at around line 690, there's some code that
null's out the random variable.
It seems like this doesn't take into account the use of /dev/urandom. So, a
call to StandardManager.stop() doesn't close the file handle. Shouldn't
there be something like:
if (randomIS!=null) {
try {
randomIS.close();
} catch (IOException ioe) {
} finally {
randomIS=null;
}
}
Inserted into either StandardManager.stop() or ManagerBase.destroy()?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -Original Message-
> From: George Sexton [mailto:geor...@mhsoftware.com]
> Sent: Friday, August 14, 2009 8:40 PM
> To: 'Tomcat Developers List'
> Subject: RE: /dev/urandom usage
>
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Friday, August 14, 2009 5:57 PM
> > To: Tomcat Developers List
> > Subject: Re: /dev/urandom usage
> >
> > George Sexton wrote:
> > > I've got a question and it's kind of deep developer question.
> > >
> > > I was poking around today looking at my tomcat instance running
> under
> > Linux.
> > >
> > > I was looking in the /proc//fd directory, which is the list of
> > file
> > > descriptors open by my servlet application.
> > >
> > > There are around 1400 open file descriptors. What I don't
> understand
> > is why
> > > there are some 800+ file descriptors that are open to /dev/urandom.
> > On this
> > > particular host there are some 400 configured hosts/contexts.
> > >
> > > On another server, there are 1100 file descriptors open to
> > /dev/urandom. For
> > > this server, there are around 200 configured hosts/contexts.
> > >
> > > I'm using Sun JDK 1.6.0_14 on OpenSUSE 11.1. One machine is amd64
> > > architecture, while the other is i386.
> > >
> > > Does anyone have any idea what could be causing this? It seems kind
> > of
> > > strange to have 800-1200 file descriptors open to one pseudo file.
> >
> > Take a look at ManagerBase.getRandom(). The probably explains the
> > majority of it.
> >
> > Mark
>
> H. You'll have to execuse me if this is a dumb question, but does
> that
> mean that each session is creating its own instance of
> java.security.SecureRandom, and each instance of
> java.security.SecureRandom
> is opening /dev/urandom?
>
>
>
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Sven Köhler wrote: And it seems to be the case, that people don't use names containg the = character but rather use values that do which was possible with the old behaviour - and indeed seems to me to be the use-case used much more often then the "name contains =" use-case. I got bit on this once. My app was using = in the value. Worked great under Tomcat 5, but under 4.0 (I think) it didn't work. I ended up forcing my cookie types to v1. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorder the http header generated by tomcat
Jim Jagielski wrote: Why? Evidently because he doesn't understand how to write a sort routine that will put them in the order he would like... So, he wants you to do it for him. I can sort of understand the desire. I had to write an iCal parser, and it turns out that it's a lot easier to do if the order of the fields is somewhat deterministic. Still, it's no excuse for not handling it in his own code if his code has a dependency on the order. On Mar 5, 2008, at 1:07 AM, Hanks Wang (hanwan) wrote: Hi all, I'd like to describe my problem clearer: Currently the http header which generated by Tomcat is something like: Accept-Ranges: none Content-Type: text/plain Server: test123 Can I change it into below order? Server: test123 Accept-Ranges: none Content-Type: text/plain Thanks! Han -Original Message- From: Hanks Wang (hanwan) Sent: Wednesday, March 05, 2008 10:12 AM To: Tomcat Developers List Subject: Reorder the http header generate by tomcat Hi all, I edit server.xml as: ... It will add "server" item in my response header, so now the http header is something like: Cache-Control: no-store, no-cache, must-revalidate Accept-Ranges: none Content-Type: text/plain Connection: close Server: test123 The "Server" is put to the last item of the http header. So my question is : Is there a way to reorder the http header instead of having tomcat formulate them? Thanks Hanks - 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] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorder the http header generated by tomcat
William A. Rowe, Jr. wrote: Jim Jagielski wrote: Requiring any specific order on HTTP response headers is completely bogus... :) To elaborate on why Jim thinks so (and we all agree)... - it's not spec. You cannot rely on this when authoring a user agent. - proxies can and will reorder whatever pretty order you assign to the response headers from the server agent. I agree. I just said that if HIS app requires a specific order, HE should write code to do it. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorder the http header generated by tomcat
Filip Hanik - Dev Lists wrote: George Sexton wrote: I agree. I just said that if HIS app requires a specific order, HE should write code to do it. that wont help you IF there is a proxy between server and user agent that reorders it. the user-agent is what needs to be fixed Filip I was working on the assumption that he's writing his own user agent and for whatever reason it simplifies his code if the headers are in a specific order. As I wrote in my original message, sometimes if you can get things in a specific order it makes things easier. The example I gave was an iCal parser. It turns out to be 10 times easier to write an iCal parser if you can get the fields in a specific order. I.E. have the DTSTART come before the RRULE every time. So, my iCal parser has a sort routine that puts the various parts of an iCal entry in a specific order BEFORE I try to use them. So, there are valid cases where when parsing data (e.g. header data) getting things in a specific order is desirable. I wholly agree that anyone that expects headers coming from a server to be in a specific order needs their head examined. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 candidate binaries
or additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat + SSL
You should start by looking at the documentation here: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html If you have additional questions, you should post those questions on the Tomcat-User list, not the tomcat-developer list. OUJGHA Radouane wrote: Hi all; I hope that you can, help me to resolve this problem : I 'm developping web services client in java with xfire, Tomcat and eclipse3.4 and I want to enable a SSL HTTP Connectoion beethwin my client and the server : I know that there will be certificat to install but I do not how to ? I'm confused : Must I invoke https connection to the services in my client java code ?? or just I need to enable this in tomcat server. thanks in advance. best regards . -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
Filip, I know I don't count, but since the build is broken when running the security manager I would have to say > [x] Broken To have a build that breaks an application because the container is violating security policy looking for a non-existent file is just not acceptable. In order for me to use this build I would have to install the patch, and recompile to have a working installation. This is what I'm doing right now to run 5.5.26. Filip Hanik - Dev Lists wrote: The candidates binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.27/ According to the release process, the 5.5.27 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
David Rees wrote: On Tue, Sep 2, 2008 at 12:01 PM, George Sexton <[EMAIL PROTECTED]> wrote: To have a build that breaks an application because the container is violating security policy looking for a non-existent file is just not acceptable. In order for me to use this build I would have to install the patch, and recompile to have a working installation. This is what I'm doing right now to run 5.5.26. I'm not a committer (or voter) either, but IMO, because this is not a regression, it should not hold up the release, especially because the release contains other potentially serious security fixes. If this were a regression, I would agree with you. I guess I'm not understanding how you use the term regression. 5.5.25 for sure did not have this problem. 5.5.26 introduced it, and 5.5.27 has it. How do you mean regression? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
William A. Rowe, Jr. wrote: George Sexton wrote: I guess I'm not understanding how you use the term regression. 5.5.25 for sure did not have this problem. 5.5.26 introduced it, and 5.5.27 has it. How do you mean regression? x.y.-1 was free of it and x.y.-0 demonstrated it. This is x.y.-2 is free of it, x.y.-1 demonstrated it, and x.y.-0 still has it. From the perspective of a release manager, this is no reason to stop the release. It's certainly a good idea to do *another* release in the near future to address it, but not to keep the fixes between 5.5.26 and 5.5.27 out of users' hands. I think using your definition, it is then a regression. For me this is a critical error. Tomcat 5.5.26 and 5.5.27 don't work when run under the security manager. It's really not a trivial corner case. Did you look at my stack trace from Saturday? Trying to open a socket in one part of my code triggered the bug. The class loader is looking for a logging.properties in context/WEB-INF/classes and it's bombing. I'm really not trying to be overly picky here, but if the whole security manager functionality is broken, that's a pretty big thing. The fact that it was broken in the last release, and will be broken in the new release is even worse. From now until the NEXT release is created, people will be posting it as a bug, which will then get marked RESOLVED, INVALID. They will then re-open and wonder why it was closed. It will then be explained that the fix is in CVS and that's why it was closed. The end user will then want to know when the release with the fix will be present. Whatever. I've made my opinion known. If the release gets done with the bug still in it, then I'm a big enough boy to apply the patch and re-compile it so things work. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
Rainer Jung wrote: As far as I understand the issue, the solution is to use the correct security manager profile. In catalina.policy there is already a comment how to do that (search for "per context logging"). I'm not doing per context logging and I don't want to. That's what I find terribly frustrating. Something I'm not trying to do is breaking my app. I have 250+ virtual hosts per tomcat instance. It seems like a lot of overhead that I'm not interested in. Even with Marks patch (or with his plus mine), there would still be the problem of the container not able to read logging.properties from a context without giving it permissions. Since I have no desire to do per-context logging, this doesn't bother me. > The only difference that the patch makes, is that it swallows the exception resp. logs it. Can you shortly describe - if adding the correct configuration to catalina.policy fixes your problem How would I add the correct configuration to catalina.policy for 250 virtual hosts/contexts into catalina.policy? It seems to me that I would have to either make many entries or make one generic entry that over-assigns permissions. Complicating matters, using the host manager, I deploy new virtual hosts/contexts on the fly while the servlet engine is running. Is there a mechanism for dynamically updating catalina.policy? - why not having those lines breaks your application and this breakage is not happening with the patch? Is it because the AccessControlException is not caught? Yes. The AccessControlException is not caught within Tomcat, and it terminates the execution of my servlet. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
Rainer Jung wrote: As far as I understand the issue, the solution is to use the correct security manager profile. In catalina.policy there is already a comment how to do that (search for "per context logging"). Just to be perfectly clear. This bug means that tomcat will not work in security manager mode UNLESS per-context logging is configured in catalina.policy. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
I will try a wild-card permission and see what happens.
Rainer Jung wrote:
George Sexton schrieb:
Rainer Jung wrote:
I have 250+ virtual hosts per tomcat instance. It seems like a lot of
overhead that I'm not interested in.
How would I add the correct configuration to catalina.policy for 250
virtual hosts/contexts into catalina.policy?
It seems to me that I would have to either make many entries or make one
generic entry that over-assigns permissions.
Complicating matters, using the host manager, I deploy new virtual
hosts/contexts on the fly while the servlet engine is running. Is there
a mechanism for dynamically updating catalina.policy?
How about adding something like
permission java.io.FilePermission
"${catalina.base}${file.separator}webapps/-", "read";
to the block starting with
grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar"
The security manager should mainly protect you somehow against malicious
webapp code. So giving those permissions to tomcat-juli doesn't seem to
be to big a problem. You can even narrow that down to giving it only to
the class org.apache.juli.ClassLoaderLogManager.
I don't know how the file system layout of the webapps for all your
vhosts looks like, but wouldn't something like this be a good compromise
for 5.5.27?
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL: http://www.mhsoftware.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
Rainer Jung wrote:
George Sexton schrieb:
I will try a wild-card permission and see what happens.
Thank you. One caveat: I tried to end it the path with
"${file.separator}-", but that doesn't work. When using the trailing "-"
syntax, you really have to use a real file separator, not the variable :(
Thanks for the tip. That probably would have driven me nuts.
I tried the wild card permission, and it does "solve" the problem. I had
to give the permission to the top of my webapps directory. I did a quick
audit of the code, and don't see anything that global read would be bad
for.
If you modify catalina.policy to "solve" the problem, you're opening
things up in the future for a security hole. Someone will add something
to the jar that can do an arbitrary read and then bang, there's a major
vulnerability staring at you.
From a philosophical standpoint, having to create a policy log entry so
the system doesn't throw an exception looking for a non-existent file is
not desirable.
--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL: http://www.mhsoftware.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tomcat5.exe on Windows x64
Before I get flamed, I looked at a way to report this bug through bugzilla/jira and couldn't seem to find the right project... I just went through a troubleshooting session getting tomcat5.exe to work on Windows 2008 x64 with x64 jre 1.6.0 Update 11. I was using the tomcat5.exe x64 binaries that I downloaded from svn. The JVM the service was created with was "auto". Attempts to start the service wrote: [2008-12-10 10:04:24] [174 javajni.c] [error] The specified module could not be found. [2008-12-10 10:04:24] [994 prunsrv.c] [error] Failed creating java [2008-12-10 10:04:24] [1269 prunsrv.c] [error] ServiceStart returned 1 in the jakarta_server_x.log file. After fooling around with it, I noticed that the jre installer created bad registry entries for HKLM\Software\JavaSoft\Java Runtime Engine\1.6\RuntimeLib the value was: C:\Program Files\Java\jre6\bin\client\jvm.dll The issue is that this file does not exist. Evidently, the Windows x64 JRE does not include the client JVM, only the server jvm. The file: C:\Program Files\Java\jre6\bin\server\jvm.dll does exist. If I manually edit the registry entry, the service starts as expected. I've submitted this as an installer bug to Sun. It might be helpful if the code in tomcat5.exe actually checked for the existence of the jvm. It would have saved a lot of trouble if the log entry had actually said something like: "Configured JVM: C:\Program Files\Java\jre6\bin\client\jvm.dll does not exist. Check the configured value for the JVM." even: "The specified module (C:\Program Files\Java\jre6\bin\client\jvm.dll) could not be found." would be an improvement. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat5.exe on Windows x64
When I looked at the Commons-Daemon one, all of the entries were 3 or more years old, so I didn't think it was in use. Mark Thomas wrote: George Sexton wrote: Before I get flamed, I looked at a way to report this bug through bugzilla/jira and couldn't seem to find the right project... Commons daemon - it is in JIRA although it really is a Sun bug and a commons-daemon enhancement request. Mark I just went through a troubleshooting session getting tomcat5.exe to work on Windows 2008 x64 with x64 jre 1.6.0 Update 11. I was using the tomcat5.exe x64 binaries that I downloaded from svn. The JVM the service was created with was "auto". Attempts to start the service wrote: [2008-12-10 10:04:24] [174 javajni.c] [error] The specified module could not be found. [2008-12-10 10:04:24] [994 prunsrv.c] [error] Failed creating java [2008-12-10 10:04:24] [1269 prunsrv.c] [error] ServiceStart returned 1 in the jakarta_server_x.log file. After fooling around with it, I noticed that the jre installer created bad registry entries for HKLM\Software\JavaSoft\Java Runtime Engine\1.6\RuntimeLib the value was: C:\Program Files\Java\jre6\bin\client\jvm.dll The issue is that this file does not exist. Evidently, the Windows x64 JRE does not include the client JVM, only the server jvm. The file: C:\Program Files\Java\jre6\bin\server\jvm.dll does exist. If I manually edit the registry entry, the service starts as expected. I've submitted this as an installer bug to Sun. It might be helpful if the code in tomcat5.exe actually checked for the existence of the jvm. It would have saved a lot of trouble if the log entry had actually said something like: "Configured JVM: C:\Program Files\Java\jre6\bin\client\jvm.dll does not exist. Check the configured value for the JVM." even: "The specified module (C:\Program Files\Java\jre6\bin\client\jvm.dll) could not be found." would be an improvement. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat5.exe on Windows x64
George Sexton wrote: When I looked at the Commons-Daemon one, all of the entries were 3 or more years old, so I didn't think it was in use. At least the change log didn't have anything more current than 3 years... -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat5.exe on Windows x64
One other comment. It appears that this executable is explicitly setting the access flags so that registry entries are created in the HKLM\Software\Wow6432Node. I don't see any good reason for this. I notice that the ISAPI redirector does not set this flag, so it depends upon the appropriate keys being in HKLM\Software. It seems to me that things should be consistent and I think that since 64 bits is the future, the keys that procrun creates should be written to the 64 bit registry, and not the Wow6432Node. jean-frederic clere wrote: George Sexton wrote: George Sexton wrote: When I looked at the Commons-Daemon one, all of the entries were 3 or more years old, so I didn't think it was in use. At least the change log didn't have anything more current than 3 years... I will try to check the JIRA's of commons=daemon and fix what needed to be fix around Christmas. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Problem with ISAPI Redirector
I posted this a couple of days ago on tomcat-user but did not get any response. I'm having a problem using the ISAPI redirector. I making the request, and I get back a 400 Bad Request response. I've gone through the troubleshooting doc, and the howto for the redirector and come up blank. I've also searched the net for the issue. I'm using version 1.2.27 of the ISAPI redirector (but 1.2.28 does the same thing) and Apache Tomcat 5.5.27. Using the IIS administration program, I created a jakarta virtual directory and made it executable. The path points to the directory containing the isapi_redirect.dll. Added the isapi_redirect.dll to the ISAPI Filters for the desired virtual host. Added the isapi_redirect.dll to the list of allowed web extensions. I'm not getting a Green Up-Arrow on the ISAPI redirect filters page. I've done the following: Made the appropriate registry entries. I'm able to get the log file, so I'm confident the registry entries are good. Set the permissions so that the user the web service runs as has read permissions to the configuration directories and write permissions to the log directory. Created the workers.properties: worker.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8010 Created the uriworkermap.properties: /calendar/*=ajp13 Configured the server.xml: I've set the level for the isapi log file to debug. When I make a request for the page: http://www.heard.org/calendar/ I get the following log output: http://www.mhsoftware.com/~gsexton/isapi_redirect.log You can see that it's finding the configuration files, and it's mapping the request into the worker but I'm getting a 400 bad request. About the only thing I notice is that the server has multiple application pools set up. At this point I'm stumped. Does anyone have any ideas on what I can try next? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Is a servlet container compliant if?
Say you have a deployment descriptor: MapTest com.mhsoftware.maptest.servlet.MapTest MapTest /MapTest.xyz Is a container compliant with the Servlet API Specification if it does not pass requests for /context/MapTest.xyz to the MapTest servlet? My reading of Servlet API 2.4 Specification, paragraph 11.2.1: "A servlet container is allowed to make other implicit mappings as long as explicit mappings take precedence. For example, an implicit mapping of *.shtml could be mapped to include functionality on the server." is that if an explicit mapping exists in the deployment descriptor for /MapTest.xyz, then to be compliant the container must pass the request to the mapped servlet, and not invoke the "implicit" mapping. Is this correct? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 5.5 Startup - Source Code Question
I have a question about how Tomcat 5.5 starts up. I'm looking through the
source code of 5.5.28 trying to follow it and I'd appreciate it if someone
could clarify a point or two for me.
>From reading the server.xml, the hierarchy of containers in Tomcat is:
Server
Service
Engine
Host
I'm not using contexts declared in the server.xml so I'm omitting them.
Looking through the source code, the classes seem to be defined in the same
hierarchy. There's StandardServer, StandardService, StandardEngine,
StandardHost.
It looks like StandardEngine.start() invokes ContainerBase.start() which I'm
guessing starts each one of the hosts using this loop:
Container children[] = findChildren();
for (int i = 0; i < children.length; i++) {
if (children[i] instanceof Lifecycle)
((Lifecycle) children[i]).start();
}
Is this interpretation correct? If not, could someone point me towards the
right direction?
My server.xml has over 300 hosts defined and startup time is getting pretty
big. There doesn't seem to be a difference in startup time between a quad
core server and a single core server. It appears to me this is because
startup of the hosts is sequential. In the best of all possible worlds it
would be nice if 4 cores means 4x faster startup.
George Sexton
MH Software, Inc.
303 438-9585
www.mhsoftware.com
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
