Re: Tomcat 6.0 documentation: is classloading description correct?
Ok, the problem is my misunderstanding of the process here. I thought WebAppClassLoader always checked WEB-INF/lib before delegating; I see that it actually delegates to the System loader first, then checks WEB-INF/lib, and finally delegates to its own parent. So my comment earlier about "they can't both be right" was of course wrong - not only *can* they be both right, they *are* :) This explains the technical problem I've been chasing; I'll have it fixed in a jiffy now. Thanks all. --Pete Konstantin Kolinko wrote on 06/17/2010 08:37:56 AM: > 2010/6/16 : > > > > Looking at section 10 of the 6.0 user guide, which describes classloading, > > the text makes perfect sense and matches the way I understand things work. > > However the summary at the end of the section "Class Loader Definitions" > > looks wrong; it basically says that the search order is... > > > > Bootstrap > > $CLASSPATH > > WEB-INF/classes > > WEB-INF/lib/*.jar > > $CATALINA_HOME/lib > > $CATALINA_HOME/lib/*.jar > > > > ...when my understanding is it should be... > > > > WEB-INF/classes > > WEB-INF/lib/*.jar > > Bootstrap > > $CLASSPATH > > $CATALINA_HOME/lib > > $CATALINA_HOME/lib/*.jar > > > > So, is the documentation just wrong, or have I misunderstood something? > > > > The order is > > Bootstrap > > $CLASSPATH > > WEB-INF/classes > > WEB-INF/lib/*.jar > > $CATALINA_BASE/lib > > $CATALINA_BASE/lib/*.jar > > $CATALINA_HOME/lib > > $CATALINA_HOME/lib/*.jar > as documented. > > Note, that many Bootstrap and $CLASSPATH classes are loaded at early > stages of Tomcat startup sequence, that is before classloading > hierarchy itself is created. It would be a mess if those classes > were ignored. > > That is why people should not play with $CLASSPATH, unless in certain > very rare cases. > > > If you have some documentation changes in your mind, the patches are > welcome. The sources are in webapps/docs/*.xml . Create a Bugzilla > issue and attach a diff file there (svn diff or an 'Unified diff' > (diff -u)). > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0 documentation: is classloading description correct?
"Caldarale, Charles R" wrote on 06/16/2010 09:55:19 PM: > > From: peter_f...@blm.gov [mailto:peter_f...@blm.gov] > > Subject: Re: Tomcat 6.0 documentation: is classloading description > > correct? > > > > The docs say in one place that the order is one way (WebApp > > first, then Boot, System and Common, which is as I'd expect) > > Please document where it says that; make sure not to ignore the > sentence: "There are exceptions." Also, don't assume that the > complete list of exceptions is described in that paragraph rather > than the bulleted list. The exceptions it gives are the ones I'd expect - no overriding JRE classes, servlet classes ignored, use of the endorsed override mechanism. I'm really more interested in the non-exceptional case of simply loading my application classes and those from third-party jars such as Apache Commons packages. > > > I need confirmation that that second part of the documentation > > is in error (or not, of course). > > All parts of the classloader doc appear to be correct to me, also > confirmed by a quick glance at the code. I don't see how that can be the case: "When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking ... All other class loaders in Tomcat 6 follow the usual delegation pattern." But then it says, this, which describes a different search order: Bootstrap classes of your JVM System class loader classes (described above) /WEB-INF/classes of your web application /WEB-INF/lib/*.jar of your web application $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar They can't *both* be right. --Pete > > You might want to look at the API spec for the class of interest: > http://tomcat.apache.org/tomcat-6.0- > doc/api/org/apache/catalina/loader/WebappClassLoader.html > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. If you received this in error, please contact the sender > and delete the e-mail and its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0 documentation: is classloading description correct?
When I wrote "CLASSPATH" I meant the classpath value that's built up by the catalina.sh - I'm well aware that it creates this from clean. I think you're missing the point; CLASSPATH is used to set the System classloader's search path, sure - but the question is where that loader fits into the loader search order used by Tomcat. The docs say in one place that the order is one way (WebApp first, then Boot, System and Common, which is as I'd expect) but in another place right after that says that it's Boot, System, WebApp, Common (which I think is wrong). I need confirmation that that second part of the documentation is in error (or not, of course). Gurkan Erdogdu wrote on 06/16/2010 03:04:08 PM: > Use "Class Loader Definitions" carefully, > > System - This class loader is normally initialized from the contents > of the CLASSPATH environment variable. > All such classes are visible to both Tomcat internal classes, and to > web applications. However, the standard Tomcat 6 startup scripts > ($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat) > totally ignore the > contents of the CLASSPATH environment variable itself, and > instead build the System class loader from the following repositories: > > > I think that documentation is correct, > > > --Gurkan > > > > From: "peter_f...@blm.gov" > To: users@tomcat.apache.org > Sent: Wed, June 16, 2010 9:42:35 PM > Subject: Tomcat 6.0 documentation: is classloading description correct? > > > Looking at section 10 of the 6.0 user guide, which describes classloading, > the text makes perfect sense and matches the way I understand things work. > However the summary at the end of the section "Class Loader Definitions" > looks wrong; it basically says that the search order is... > > Bootstrap > $CLASSPATH > WEB-INF/classes > WEB-INF/lib/*.jar > $CATALINA_HOME/lib > $CATALINA_HOME/lib/*.jar > > ...when my understanding is it should be... > > WEB-INF/classes > WEB-INF/lib/*.jar > Bootstrap > $CLASSPATH > $CATALINA_HOME/lib > $CATALINA_HOME/lib/*.jar > > So, is the documentation just wrong, or have I misunderstood something? > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0 documentation: is classloading description correct?
Looking at section 10 of the 6.0 user guide, which describes classloading, the text makes perfect sense and matches the way I understand things work. However the summary at the end of the section "Class Loader Definitions" looks wrong; it basically says that the search order is... Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar ...when my understanding is it should be... WEB-INF/classes WEB-INF/lib/*.jar Bootstrap $CLASSPATH $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar So, is the documentation just wrong, or have I misunderstood something? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
David kerber wrote on 05/17/2010 12:43:17 PM: > On 5/17/2010 2:19 PM, peter_f...@blm.gov wrote: > > "Caldarale, Charles R" wrote on 05/17/2010 > > 12:14:21 PM: > > > >>> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > >>> Subject: RE: Misunderstanding deployOnStartup actions > >>> > >>> The only 100% secure system is one that is turned off. > >> > >> Not sure even that is sufficient... > >> > >> - Chuck > > > > You could seal the hard drive in concrete then sink it in the Challenger > > Deep... and there's still the chance that some Dr. Evil wannabe would > > develop a sub to locate and retrieve it... > > I prefer wiping the drive eleven times with cryptographically-sound > random data, then grinding the entire computer to a fine talcum-powder > consistency, mixing it thoroughly with twenty pounds of dry powdered > cement, then stir in the water and gravel to make concrete. When it > starts to get thick, start stirring in the ten pounds of small > rare-earth magnets, one at a time. Let it set, then dip it repeatedly in > molten steel. Finally, use a high-powered electromagnet to lift and drop > the resulting brick into the hot part of an active volcano, then push > the planet it's on into the nearest star. > > I suppose an attacker *might* not be able to recover the data if you > skipped the last step, but why take chances? > > :-D > > (I wish I had come up with this one, but can't claim it...) > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > ...Or, I could give it to my kids and ask them *not* to destroy it... Pete - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
"Caldarale, Charles R" wrote on 05/17/2010 12:14:21 PM: > > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > > Subject: RE: Misunderstanding deployOnStartup actions > > > > The only 100% secure system is one that is turned off. > > Not sure even that is sufficient... > > - Chuck You could seal the hard drive in concrete then sink it in the Challenger Deep... and there's still the chance that some Dr. Evil wannabe would develop a sub to locate and retrieve it... :) > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. If you received this in error, please contact the sender > and delete the e-mail and its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Well, it's the usual thing - you can have a system that's completely open but gets cratered because some duffer clicked the wrong button. Or you can have a system that's 100% secure, but nobody can use it because it's 100% secure. Or you can have something that's "secure enough" to protect from accidents and any but the most determined black hat, which is really what I'm aiming for here. Pete Pid wrote on 05/17/2010 11:47:52 AM: > On 17/05/2010 18:14, peter_f...@blm.gov wrote: > > Pid wrote on 05/17/2010 10:55:06 AM: > > > >> On 17/05/2010 17:48, peter_f...@blm.gov wrote: > >>> To clarify what I'm up to here - we have an in-house doc that suggests > >>> switching off autoDeploy and deployOnStartup on production systems, and > >> > >> Does it explain why it makes this suggestion? > > > > To prevent someone accidentally (or otherwise, of course) deploying an > > application in a production system simply by dropping in a WAR. > > > >> > >>> I've been testing those recommendations on an experimental setup. What > > the > >>> in-house doc forgets to say is what you've explained here (and which > >>> answers my original question - thanks!) which is that you have to put a > >>> Context element into the server.xml to make it work. > >> > >> Which is explicity discouraged in current versions of Tomcat. > > > > Yes, but in a fixed production setting it makes sense. At least in that > > setting you'd have to be able to edit server.xml, which is not something > > you're going to do by accident. > > With the right settings, you'd still need to restart the server, even if > someone had managed to accidentally update the war files. > > Seems a little paranoid, but hey... > > > p > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Pid wrote on 05/17/2010 10:55:06 AM: > On 17/05/2010 17:48, peter_f...@blm.gov wrote: > > To clarify what I'm up to here - we have an in-house doc that suggests > > switching off autoDeploy and deployOnStartup on production systems, and > > Does it explain why it makes this suggestion? To prevent someone accidentally (or otherwise, of course) deploying an application in a production system simply by dropping in a WAR. > > > I've been testing those recommendations on an experimental setup. What the > > in-house doc forgets to say is what you've explained here (and which > > answers my original question - thanks!) which is that you have to put a > > Context element into the server.xml to make it work. > > Which is explicity discouraged in current versions of Tomcat. Yes, but in a fixed production setting it makes sense. At least in that setting you'd have to be able to edit server.xml, which is not something you're going to do by accident. Pete > > > p > > > I need to get our doc corrected. > > > > Problem solved. Thanks all. > > > > Pete > > > > Mark Thomas wrote on 05/17/2010 10:38:11 AM: > > > >> On 17/05/2010 17:33, peter_f...@blm.gov wrote: > >>> Mark Thomas wrote on 05/17/2010 10:12:20 AM: > Not pointless. It limits deployed apps to *only* those defined in > server.xml. > >>> > >>> Ok - so if I want my app to start I have to place the context element > > in > >>> server.xml. I would have thought that an external context.xml would > > have > >>> the same effect (I thought that was the point) but I'm not seeing that > >>> happen; maybe got something wrong in that file. > >> > >> No. context.xml files are deployed via the auto-deploy process so they > >> need deployOnStartup or autoDeploy to be true. When I wrote "*only* > >> those defined in server.xml" that is exactly what I meant. > >> > That is plain wrong. autoDeployment /deployOnStartup do play a role in > double-deployment but only when your configuration is wrong to start > >>> with. > >>> > >>> Well, I guess I'll just have to be careful with my configuration :) > >>> (seriously, unless I missed it in the documentation it wasn't clear on > >>> double-deployment as a consequence of bad config.) > >> > >> Explicit definition in server.xml + autoDeploy == double deployment. > >> I'll add a few words to the docs to try and clarify that. > >> > >> Mark > >> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > [attachment "signature.asc" deleted by Peter Ford/NOC/BLM/DOI] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
To clarify what I'm up to here - we have an in-house doc that suggests switching off autoDeploy and deployOnStartup on production systems, and I've been testing those recommendations on an experimental setup. What the in-house doc forgets to say is what you've explained here (and which answers my original question - thanks!) which is that you have to put a Context element into the server.xml to make it work. I need to get our doc corrected. Problem solved. Thanks all. Pete Mark Thomas wrote on 05/17/2010 10:38:11 AM: > On 17/05/2010 17:33, peter_f...@blm.gov wrote: > > Mark Thomas wrote on 05/17/2010 10:12:20 AM: > >> Not pointless. It limits deployed apps to *only* those defined in > >> server.xml. > > > > Ok - so if I want my app to start I have to place the context element in > > server.xml. I would have thought that an external context.xml would have > > the same effect (I thought that was the point) but I'm not seeing that > > happen; maybe got something wrong in that file. > > No. context.xml files are deployed via the auto-deploy process so they > need deployOnStartup or autoDeploy to be true. When I wrote "*only* > those defined in server.xml" that is exactly what I meant. > > >> That is plain wrong. autoDeployment /deployOnStartup do play a role in > >> double-deployment but only when your configuration is wrong to start > > with. > > > > Well, I guess I'll just have to be careful with my configuration :) > > (seriously, unless I missed it in the documentation it wasn't clear on > > double-deployment as a consequence of bad config.) > > Explicit definition in server.xml + autoDeploy == double deployment. > I'll add a few words to the docs to try and clarify that. > > Mark > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Mark Thomas wrote on 05/17/2010 10:12:20 AM: > On 17/05/2010 16:56, peter_f...@blm.gov wrote: > > > > I'm a bit confused about what the deployOnStartup setting is supposed to > > do, especially when it's set to "false". > > It controls if apps are deployed when Tomcat starts. > > > The basic question is, what is the purpose of this setting? It would appear > > that if you set it to "false", then applications can only be started by > > being hot-deployed, which seems rather odd but I suppose might be useful in > > a development environment. By experiment I found that setting > > autoDeploy=true and deployOnStartup=false, existing webapps are still > > started but not until after Tomcat has already started (that is, the > > applications get deployed a few seconds after Tomcat has started and is > > listening, rather than during the usual startup sequence). > > That will be hot-deployment kicking in ~15 secs after Tomat starts. ...which confirms what I was thinking. > > > I also found > > that setting autoDeploy=false and deployOnStartup=false, no applications > > will start (which is actually what I'd expect, even though it's pointless). > > Not pointless. It limits deployed apps to *only* those defined in > server.xml. Ok - so if I want my app to start I have to place the context element in server.xml. I would have thought that an external context.xml would have the same effect (I thought that was the point) but I'm not seeing that happen; maybe got something wrong in that file. > > > My guess would be that in a production setting you'd want > > autoDeploy=false/deployOnStartup=true. > > That is usually what I see. > > > There's a couple of places in documentation (online, and also in the > > O'Reilly book) where it says you shouldn't have hot-deployment AND > > deployOnStart enabled because it can result in applications being deployed > > twice - and yet the default is that autoDeploy and deployOnStartup are both > > true, which seems to contradict that, and in any case I've never seen this > > happen. I'm plainly misunderstanding how these settings are supposed to > > work. Perhaps someone here can clarify? > > That is plain wrong. autoDeployment /deployOnStartup do play a role in > double-deployment but only when your configuration is wrong to start with. Well, I guess I'll just have to be careful with my configuration :) (seriously, unless I missed it in the documentation it wasn't clear on double-deployment as a consequence of bad config.) Pete > > Mark > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Notes inline... "Caldarale, Charles R" wrote on 05/17/2010 10:11:47 AM: > > From: peter_f...@blm.gov [mailto:peter_f...@blm.gov] > > Subject: Misunderstanding deployOnStartup actions > > > > > > I'm a bit confused about what the deployOnStartup setting is > > supposed to do, especially when it's set to "false". > > It defers webapp deployment until after the container is up and > running. Some external event is required to trigger the deployment. That makes sense, but doesn't seem to happen - see below (1). > > > > > if you set it to "false", then applications can only be > > started by being hot-deployed > > No, you can use the manager or equivalent APIs to do the deployment, > or you can configure the webapp in server.xml (not recommended). The setup I have has all the delivered applications (manager, docs, etc.) stripped out. There's just my application. I didn't place a context in server.xml although I've tried it with a conf/Catalina/localhost/[my-app-name].xml context entry, which doesn't seem to have any effect. > > > I found that setting autoDeploy=true and deployOnStartup=false, > > existing webapps are still started but not until after Tomcat > > has already started > > As expected; the first request to the webapp triggers deployment. (1) - but the app is deployed after a few seconds even when there is no request (and if autoDeploy and deployOnStartup are both false, the app still doesn't start on a request and I get a blank response). > > > I also found that setting autoDeploy=false and deployOnStartup=false, > > no applications will start > > IIRC, any configured in server.xml will be started. I haven't tried that (as I mentioned, I use an external context.xml but it doesn't seem to have an effect). > > > There's a couple of places in documentation (online, and also in the > > O'Reilly book) where it says you shouldn't have hot-deployment AND > > deployOnStart enabled because it can result in applications being > > deployed twice > > Not true; double deployment occurs when you badly configure a webapp > located in the appBase directory, such as having its > element in server.xml with a path attribute that does not match the > name of the .war file or directory. Ok, that makes sense. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. If you received this in error, please contact the sender > and delete the e-mail and its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Oops, forgot to say. I'm on 6.0.26. The online documentation I read is at: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment ...which is very clear about what happens with deployOnStartup="true" but as far as I can see gives no details about what's supposed to happen when it's set "false". Pete Konstantin Kolinko wrote on 05/17/2010 10:05:10 AM: > 2010/5/17 : > > There's a couple of places in documentation (online, and also in the > > O'Reilly book) where it says you shouldn't have hot-deployment AND > > deployOnStart enabled because it can result in applications being deployed > > twice > > 1. For what Tomcat version? > 2. Where online? Is it anywhere at http://tomcat.apache.org/ ? > > > - and yet the default is that autoDeploy and deployOnStartup are both > > true > > Yes, I can confirm that they are both true by default. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Misunderstanding deployOnStartup actions
I'm a bit confused about what the deployOnStartup setting is supposed to do, especially when it's set to "false". The basic question is, what is the purpose of this setting? It would appear that if you set it to "false", then applications can only be started by being hot-deployed, which seems rather odd but I suppose might be useful in a development environment. By experiment I found that setting autoDeploy=true and deployOnStartup=false, existing webapps are still started but not until after Tomcat has already started (that is, the applications get deployed a few seconds after Tomcat has started and is listening, rather than during the usual startup sequence). I also found that setting autoDeploy=false and deployOnStartup=false, no applications will start (which is actually what I'd expect, even though it's pointless). My guess would be that in a production setting you'd want autoDeploy=false/deployOnStartup=true. There's a couple of places in documentation (online, and also in the O'Reilly book) where it says you shouldn't have hot-deployment AND deployOnStart enabled because it can result in applications being deployed twice - and yet the default is that autoDeploy and deployOnStartup are both true, which seems to contradict that, and in any case I've never seen this happen. I'm plainly misunderstanding how these settings are supposed to work. Perhaps someone here can clarify? Pete - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: best practice for resources folder
Isn't ${catalina.home}/lib a place that should work with the default
catalia.properties?
Pete
Juergen Weber wrote on 05/17/2010 09:14:01 AM:
>
> Hi, this seems to be a FAQ, but I could not find a solution for Tomcat 6:
>
> We want to keep property files out of war files. Where should we put the
> property files to access them from the web app via
> Class.getResourceAsStream() ?
> For JBoss one would simply drop them into the server conf folder, for
> Geronimo one would use the SharedLib gbean.
>
> But for Tomcat? Add a server.loader path to catalina.properties ?
>
> Thanks,
> Juergen
>
> --
> View this message in context: http://old.nabble.com/best-practice-
> for-resources-folder-tp28584753p28584753.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MaxPermSize / Threads
One thing that happened on a system I was working on here, was that we saw OOMs and yet the GC stats showed we had plenty of free heap space, which didn't make sense. The problem turned out to be that there was a memory leak at the native level where the JVM couldn't see it and had no control (specifically, Apache Commons FileUpload version 1.0 used a native library function that had a leak; later versions of fileupload fixed this problem). Pete "Caldarale, Charles R" wrote on 05/17/2010 09:10:28 AM: > > From: Ozgur Ozdemircili [mailto:ozgur.ozdemirc...@gmail.com] > > Subject: Re: MaxPermSize / Threads > > > > You can see the server giving error every 3-4 minutes until it dies. > > By "it dies", do you mean you have to restart Tomcat? > > Turn on GC logging (-verbose:gc) and use a heap profiler to see if > you have a memory leak or simply an undersized heap for the load > you're putting on it. If the heap usage returns to normal after a > heavy load, your heap is undersized; if the heap usage keeps > increasing over time regardless of the load, you have a leak in your webapps. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. If you received this in error, please contact the sender > and delete the e-mail and its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recommendation for log analyzer?
The apps I work on mostly use Commons Logging + Log4J, which fits with Chainsaw as a useful tool for monitoring and analysis. Gregor Schneider wrote on 05/07/2010 02:34:21 PM: > Provided your logfiles are rolling daily: > > echo Number of errors i file: `grep "ERROR" [logfilename here] | wget -l` > > as a start. > > Seriously: > > Analyze your requirements and have somebody write a small script which > you put into your crontab. Said script can be a simple one or as > complex as you like it. > > Provided you're running on Linux, there's a whole bunch of useful > utilities (sed, awk) which could do the job. > > Rgds > > Gregor > -- > just because you're paranoid, don't mean they're not after you... > gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 > gpgp-key available > @ http://pgpkeys.pca.dfn.de:11371 > @ http://pgp.mit.edu:11371/ > skype:rc46fi > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 and FastCommonAccessLogValve
I just confirmed this myself 30 seconds before I received this :) After comparing the AccessLogValve and FastCommonAccessLogValve sources between 5.5 and 6.0 it appears my colleague is correct; in 6.0 the additional fields and methods of the Fast valve have been moved into the regular AccessLogValve. That's good news. Peter Ford, Senior Java EE Developer Contractor, NexGen Technologies, Inc. National Applications, OC-310 Division of IRM Support Services National Operations Center, BLM Office - 303-236-2261 Fax - 303-236-6691 Confidentiality Notice: This electronic communications is intended only for the use of the individual(s) or entity(ies) to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, delete the original message, and notify the sender. Mark Thomas wrote on 05/07/2010 10:26:44 AM: > On 07/05/2010 16:18, peter_f...@blm.gov wrote: > > > > Sorry for so many questions in a short space of time. This is the last > > question, I promise :) > > > > The FastCommonAccessLogValve has been deprecated but the documentation > > gives no reason why. Does anyone here know the reason? A colleague > > suggested that the functionality may have been rolled into the standard > > AccessLogValve, making the fast valve redundant, but we have it configured > > in one system here and I'm concerned that the fast valve may have been > > deprecated because of a bug or something else bad. Any ideas? > > No bug. Just no longer required. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.26 Context/privileged
I knew I had to have missed something. The documentation section that covers classloading isn't very clear and as far as I can see makes no mention of the privileged setting, and the section under Context configuration that describes the privileged setting is misleading (from your description I'd guess it wasn't updated properly from 5.5). Your answer makes things plainer. Thanks! "Caldarale, Charles R" Tomcat Users List 05/07/2010 08:44 cc AM Subject RE: Tomcat 6.0.26 Please respond to Context/privileged "Tomcat Users List" > From: peter_f...@blm.gov [mailto:peter_f...@blm.gov] > Subject: Tomcat 6.0.26 Context/privileged > > that means that in effect all applications are running as if > privileged by default. No, that's not how it works. The WebappClassLoader chooses which parent in the classloader hierarchy to delegate to, based on the privileged setting. By default, the WebappClassLoader skips over the common class loader, going right to the system classloader. Only privileged webapps get to use the common class loader. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 -security option
Yes, they're from the Chat servlet, and that answers the question. Thank you! Konstantin Kolinko wrote on 05/07/2010 08:15:28 AM: > 2010/5/7 : > > If I run bin/startup.sh with the -security option switched on, I get a > > couple of security exceptions thrown into catalina.out. Is this expected? > > Those from "chat.ChatServlet" ? Yes, they are expected. > > https://issues.apache.org/bugzilla/show_bug.cgi?id=48218 > gives details, if you are curious. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.26 and FastCommonAccessLogValve
Sorry for so many questions in a short space of time. This is the last question, I promise :) The FastCommonAccessLogValve has been deprecated but the documentation gives no reason why. Does anyone here know the reason? A colleague suggested that the functionality may have been rolled into the standard AccessLogValve, making the fast valve redundant, but we have it configured in one system here and I'm concerned that the fast valve may have been deprecated because of a bug or something else bad. Any ideas? --Pete - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.26 -security option
I'm running a Tomcat 6.0.26 on Linux with Java 6u20. This is a freshly unpacked installation; the only changes I made were in server.xml to change the shutdown port and disable the AJP port, and tomcat-users so I can log in to the manager. I haven't removed any of the supplied apps, or installed my own app. If I run bin/startup.sh with the -security option switched on, I get a couple of security exceptions thrown into catalina.out. Is this expected? --Pete - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.26 Context/privileged
Can someone clarify something about the Context element's "privileged" attribute in Tomcat 6.0? In Tomcat 5.5 setting privileged="true" would set the application's parent class loader to the Catalina loader so that the app could access the server classes. The default is privileged="false" and so normal apps don't see these classes. In Tomcat 6, if I understand the documentation, all the server class jars are handled by the common loader (which can see the server jars), and that means that in effect all applications are running as if privileged by default. More than that, even explicitly setting privileged="false" won't switch this behaviour off. The only way to change that would be to move the server jars to another directory and modify the catalina.properties. Is that right, or am I missing something about how 6.0 deals with this? If this is the way things are, doesn't that mean that 6.0 is not in line with the Servlet API spec? --Pete - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HelloWorld servlet, or just about
Actually this is very easy; when you want to pass the request down the
chain (i.e. into the servlet) you call the chain.doFilter() method. When
you *don't* want the request passed on, your filter just sets up the
response (status, header, etc.) and returns.
André Warnier wrote on 12/19/2008 02:50:25 PM:
> Ken Bowen wrote:
> > Of course, Google is your friend:
> > Results 1 - 10 of about 237,000 for hello world servlet. (0.23
> > seconds)
> > :-)
> >
> Yeah, I got that too.
> That's the problem though : which one to choose ?
>
> Never mind, and apologies, I think I'll use the first one :
>
> package test;
>
> import java.io.*;
>
> import javax.servlet.http.*;
> import javax.servlet.*;
>
> public class HelloServlet extends HttpServlet {
>public void doGet (HttpServletRequest req,
> HttpServletResponse res)
> throws ServletException, IOException
>{
> PrintWriter out = res.getWriter();
>
> out.println("Hello, world!");
> out.close();
>}
> }
>
>
> But now, a trickier question :
>
> I already have a servlet filter, in front of a servlet which I need
anyway.
> Can I, in the filter, and based on some characteristic of the request,
> return a response to the caller immediately, bypassing the servlet
> entirely ?
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 classloading and the Servlet 2.5 API spec
In hindsight that makes perfect sense and answers my question. If it was vitally important to enforce this (it isn't, but hypothetically) I guess I could mess with the catalina.policy file. --Pete "Bill Barker" To Sent by: news users@tomcat.apache.org Subject Re: Tomcat 6 classloading and the 12/15/2008 11:32 Servlet 2.5 API spec PM Please respond to "Tomcat Users List" wrote in message news:of14e2cc5d.7f3b739a-on87257520.0059a8c8-87257520.005b2...@blm.gov... > > I'm trying to clarify something about Tomcat 6 compliance to the Servlet > 2.5 spec. The spec (section 9.7.2) says: > > "The container should not allow applications to override or access the > container's implementation classes." > > In Tomcat 5 it looks like this was handled by having separate "common", > "shared" and "server" directories and the catalina.properties file > specified the classloader configuration such that application code > couldn't > get to the "server" classes and jars. In Tomcat 6, everything is rolled > into a single "lib" directory. The catalina.properties file can be > modified > to make things like the older Tomcat versions, but out of the box it looks > to me like an application could get to the catalina jar files. > > Going by a literal reading of the spec, Tomcat 6 is still technically > compliant (the spec says "should not", not "must not") but all the same it > seems a little strange that this was changed, unless there's something I'm > missing. Does Tomcat 6 have some other mechanism in place to make sure > that > applications can't access the container classes and worse, make changes to > the container's data at run time? For a long time, the Tomcat developers realized that since Java provides introspection, there was really no additional protection provided by classloader segregation if you are not using a SecurityManager sandbox. As a result, they simplified the classloader structure by default and left it up to the admin to configure the sandbox as necessary. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 classloading and the Servlet 2.5 API spec
I'm trying to clarify something about Tomcat 6 compliance to the Servlet 2.5 spec. The spec (section 9.7.2) says: "The container should not allow applications to override or access the container’s implementation classes." In Tomcat 5 it looks like this was handled by having separate "common", "shared" and "server" directories and the catalina.properties file specified the classloader configuration such that application code couldn't get to the "server" classes and jars. In Tomcat 6, everything is rolled into a single "lib" directory. The catalina.properties file can be modified to make things like the older Tomcat versions, but out of the box it looks to me like an application could get to the catalina jar files. Going by a literal reading of the spec, Tomcat 6 is still technically compliant (the spec says "should not", not "must not") but all the same it seems a little strange that this was changed, unless there's something I'm missing. Does Tomcat 6 have some other mechanism in place to make sure that applications can't access the container classes and worse, make changes to the container's data at run time?
