RE: Tomcat 6.0 documentation: is classloading description correct?
Caldarale, Charles R chuck.caldar...@unisys.com 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?
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 knst.koli...@gmail.com wrote on 06/17/2010 08:37:56 AM: 2010/6/16 peter_f...@blm.gov: 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
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: 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 gurkanerdo...@yahoo.com 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 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
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 chuck.caldar...@unisys.com 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: best practice for resources folder
Isn't ${catalina.home}/lib a place that should work with the default
catalia.properties?
Pete
Juergen Weber webe...@gmail.com 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
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: 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 knst.koli...@gmail.com wrote on 05/17/2010 10:05:10 AM: 2010/5/17 peter_f...@blm.gov: 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
RE: Misunderstanding deployOnStartup actions
Notes inline... Caldarale, Charles R chuck.caldar...@unisys.com 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 Context 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
Mark Thomas ma...@apache.org 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
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 ma...@apache.org wrote on 05/17/2010 10:38:11 AM: On 17/05/2010 17:33, peter_f...@blm.gov wrote: Mark Thomas ma...@apache.org 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
Pid p...@pidster.com 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 ma...@apache.org wrote on 05/17/2010 10:38:11 AM: On 17/05/2010 17:33, peter_f...@blm.gov wrote: Mark Thomas ma...@apache.org 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
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 p...@pidster.com wrote on 05/17/2010 11:47:52 AM: On 17/05/2010 18:14, peter_f...@blm.gov wrote: Pid p...@pidster.com 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
Caldarale, Charles R chuck.caldar...@unisys.com 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
David kerber dcker...@verizon.net wrote on 05/17/2010 12:43:17 PM: On 5/17/2010 2:19 PM, peter_f...@blm.gov wrote: Caldarale, Charles Rchuck.caldar...@unisys.com 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
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
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 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
Re: Tomcat 6.0.26 -security option
Yes, they're from the Chat servlet, and that answers the question. Thank you! Konstantin Kolinko knst.koli...@gmail.com wrote on 05/07/2010 08:15:28 AM: 2010/5/7 peter_f...@blm.gov: 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
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 Chuck.Caldarale@ To unisys.com Tomcat Users List users@tomcat.apache.org 05/07/2010 08:44 cc AM Subject RE: Tomcat 6.0.26 Please respond to Context/privileged Tomcat Users List us...@tomcat.apa che.org 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 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 ma...@apache.org 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: 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 rc4...@googlemail.com 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: 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 a...@ice-sa.com 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 wbar...@wilshire .com To Sent by: news users@tomcat.apache.org n...@ger.gmane.o cc rg Subject Re: Tomcat 6 classloading and the 12/15/2008 11:32 Servlet 2.5 API spec PM Please respond to Tomcat Users List us...@tomcat.apa che.org peter_f...@blm.gov 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?
