RE: Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting?
Holy smokes that was a quick response! Thanks!!! -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, February 24, 2011 5:47 PM To: Tomcat Users List Subject: Re: Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting? On 24/02/2011 22:44, Scott Hamilton wrote: > Is this capability somewhere else, perhaps not needed anymore, or perhaps > still on the backlog to be ported up to TC7? > See ServletContext.setSessionTrackingModes() 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
Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting?
Is this capability somewhere else, perhaps not needed anymore, or perhaps still on the backlog to be ported up to TC7?
RE: Upgrading from Tomcat 6.0.29 to 7.0.8 - TLD Scanned Location Problem
Thanks - a custom JarScanner did the trick. I'll do the bugzilla submission soon too. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, February 23, 2011 3:04 PM To: Tomcat Users List Subject: Re: Upgrading from Tomcat 6.0.29 to 7.0.8 - TLD Scanned Location Problem On 23/02/2011 19:13, Scott Hamilton wrote: > Looks like the TldConfig class changed significantly between these versions > such that now TLDs that are under WEB-INF/classes (e.g. > WEB-INF/classes/META-INF) are no longer scanned/processed. > > This is an issue for us in development as some of our MyEclipse projects are > TLD library projects that in production will be in JARs in the WEB-INF/lib > but in development get exploded into WEB-INF/classes. In 6.0.x this worked > fine for us; 7.0.8 has removed this "feature". > > I realize that the reasoning behind this was to be more spec-compliant. Actually, the reasoning was: a) make TLD scanning consistent between Catalina & Jasper b) provide the extension points required by the Virgo project for OSGI RFC66 > My question is whether there is a Tomcat work-around to this to facilitate > our development environment? I've been poking around the TC source code and > as yet see no way to do this. I was even thinking of extending TldConfig to > use a subclass as a lifecycle listener (turning off the context processTlds) > but (as far as I've looked at this approach) the methods I'd want to override > or call in TldConfig are private. :( > > Any ideas? See http://tomcat.apache.org/tomcat-7.0-doc/config/jar-scanner.html Implementing your own JarScanner that additionally scans WEB-INF/classes should do the trick in the short-term. If you open a Bugzilla issue, I'll look into providing a configuration option that allows WEB-INF classes to be treated like an exploded JAR file. 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
Upgrading from Tomcat 6.0.29 to 7.0.8 - TLD Scanned Location Problem
Looks like the TldConfig class changed significantly between these versions such that now TLDs that are under WEB-INF/classes (e.g. WEB-INF/classes/META-INF) are no longer scanned/processed. This is an issue for us in development as some of our MyEclipse projects are TLD library projects that in production will be in JARs in the WEB-INF/lib but in development get exploded into WEB-INF/classes. In 6.0.x this worked fine for us; 7.0.8 has removed this "feature". I realize that the reasoning behind this was to be more spec-compliant. My question is whether there is a Tomcat work-around to this to facilitate our development environment? I've been poking around the TC source code and as yet see no way to do this. I was even thinking of extending TldConfig to use a subclass as a lifecycle listener (turning off the context processTlds) but (as far as I've looked at this approach) the methods I'd want to override or call in TldConfig are private. :( Any ideas? Thanks in advance, Scott
RE: Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
You've got two connectors in that server.xml, and one of them is AJP without any real other configuration parameters. If memory serves the thread limit when not specified for a connector is 200... Can we assume you're using apache as a web server connecting to tomcat? What are you using there - mod_proxy_ajp? Mod_jk? What do the settings for that look like? -Original Message- From: White, Federico (Federico) [mailto:whi...@avaya.com] Sent: Tuesday, August 24, 2010 11:44 AM To: users@tomcat.apache.org Subject: Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads Hi again, Since my first email might have not be that clear I'll re phrase it, I'm currently running a Tomcat webserver for an application that my company uses. It run's on windows server 2003, and the startup command was customized for our application and is the following "C:\ProgramFiles\Avaya\IC71\tomcat\bin\tomcat5.exe"//RS//AvayaICWebManag ement71 I really don't know what's the JVM level and the meaning for APR (if its really important kindly let me know how to get it and I will) We use a customized .xml file created for our product and this is the content (note we don't have the out of the box server.xml file) Thanks -Original Message- From: White, Federico (Federico) Sent: Martes, 24 de Agosto de 2010 12:09 p.m. To: 'users@tomcat.apache.org'; 'users-h...@tomcat.apache.org' Subject: Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads I have an issue where my Tomcat server is going down quite often with the following message: Aug 19, 2010 12:03:21 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status Aug 20, 2010 4:47:20 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-9602 Aug 20, 2010 4:47:21 PM org.apache.catalina.core.StandardService stop INFO: Stopping service website Aug 20, 2010 4:47:21 PM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-9602 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.29 - deadlocks when loading shared classes
Can you also include the dump of the thread that is holding the lock? In other words, what's the other half of the deadlock? -Original Message- From: Milo Meerkat [mailto:milo.meer...@gmx.com] Sent: Monday, August 23, 2010 10:53 AM To: users@tomcat.apache.org Subject: Tomcat 6.0.29 - deadlocks when loading shared classes Hi, Setup: - Debian GNU/Linux - Java 1.6.0_21-b06 - Tomcat http://www.coderanch.com/forums/f-56/Tomcat 6.0.29 I got the error below when upgrading tomcat 5.5.29 to tomcat 6.0.29. When we upgraded we noticed that tomcat 6 does not like if we have a xerces implementation in each webapp in the tomcat instance (tomcat 5 is fine with this), so we placed the following jars in a common tomcat library (catalina property "shared.loader"): - serializer-2.7.1.jar - xalan-2.7.1.jar - xercesImpl-2.9.1.jar - xmlParserAPIs-2.6.2.jar This worked well locally and in our staging environment, but when we upgraded our production environment, we started getting thread deadlocks, and the load reached 20 in "top". Normally with tomcat 5.5 the server runs with load 2-3. We tried downgrading to tomcat 6.0.26, and we tried having only one webapp in the tomcat instance, with the four XML jars in the webapp (WEB-INF/lib), not in the shared lib. Didn't work. When we downgraded to tomcat 5.5 again, everything was back to normal. Does anyone know what I'm doing wrong here? Or is there a classloader bug in tomcat 6? Cheers! --- "TP-Processor93" daemon prio=10 tid=0x7f2f92613800 nid=0x462f waiting for monitor entry [0x43176000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1524) - waiting to lock <0x7f2fb0e575b0> (at org.apache.catalina.loader.WebappClassLoader) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491) at javax.xml.xpath.XPathFactoryFinder.createClass(XPathFactoryFinder.java:256) at javax.xml.xpath.XPathFactoryFinder.loadFromService(XPathFactoryFinder.java:363) at javax.xml.xpath.XPathFactoryFinder._newFactory(XPathFactoryFinder.java:222) at javax.xml.xpath.XPathFactoryFinder.newFactory(XPathFactoryFinder.java:143) at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:185) at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:99) ... at sun.reflect.GeneratedMethodAccessor512.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:404) at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:267) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:229) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:150) . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited.
RE: Is there a better way to disable JSESSIONID in the URLs?
Awesome dude (that you submitted the patch so quick - I've not looked at it in detail yet). Thanks! -Original Message- From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Sent: Monday, August 23, 2010 2:33 PM To: Tomcat Users List Subject: Re: Is there a better way to disable JSESSIONID in the URLs? https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas wrote: > On 22/08/2010 16:29, Wesley Acheson wrote: >> Sorry for bring this off list. I'll put it back on list if you think that >> appropriate. >> >> You think that the context is the correct place to put this? I thought maybe >> web.xml but I don't know if you can extend that or if its rigidly covered by >> the spec. > > web.xml is defined by the spec. You can't touch it. > >> I started to do this on the connector is that incorrect? > > The configuration needs to be per context. Look at the sessionCookieName > attribute as an example. > > For the place to actually diable it, look in the > o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 > code, you'll see how the Servlet 3.0 stuff was implemented. > >> How would one submit a patch? Sorry I've never done this for any project. Do >> I just attach the changed source files to bugzilla? or do I need to do a >> diff and create a patch file. > > Patch please, in diff -u format. Bugzilla is the right place. > >> I'm on windows so I've never used patch and I >> am unsure how to create one. (unix patch file) > > I use TortoiseSVN and Eclipse on Windows. Both these tools generate > suitable patch files. > > 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 . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Sorry to pull the thread back to my original problem, but I have one more question here. So far it looks like there's no way to prevent JSESSIONIDs from being injected into URLs that Tomcat might encode unless you implement a servlet filter to override that behavior. My follow-up question is this: given the increasing emphasis on security (and acknowledging that there's as much fear-mongering as there is legitimate threats involved in that business and both cost money and time regardless of the legitimacy of the issue), does it make sense to for Tomcat, and maybe even the servlet spec, to provide the option for the servlet container to disable this functionality at the container level, e.g. with a container configuration switch somewhere? . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Thanks for the reply. > Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. If the session (a) already exists and (b) was received in the request through a cookie reference it will NOT do the URL rewriting. I'm assuming this is to cover the bases and ensure a JSESSIONID gets injected into the following requests regardless of the client's cookie acceptance policy. >> And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. << You're absolutely correct, and SSL is used for our security-conscious customers. The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, August 17, 2010 6:16 PM To: Tomcat Users List Subject: RE: Is there a better way to disable JSESSIONID in the URLs? > From: Scott Hamilton [mailto:scott.hamil...@plateau.com] > Subject: Is there a better way to disable JSESSIONID in the URLs? > > there is no way to disable tomcat from putting the JSESSIONID in URLs > automatically with a nice friendly global switch/property. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. > We have an app whose security is a concern for our customers, and > JSESSIONIDs appearing in the URLs freak them out And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. - 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 . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is there a better way to disable JSESSIONID in the URLs?
Using Tomcat 6.0.29, but I think this is version-independent (correct me if I'm wrong), at least for the 6.0.x versions. >From what I understand (see http://randomcoder.com/articles/jsessionid-considered-harmful for instance - I also scanned various aspects of the tomcat source code) there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. The only way I've seen how to do this, as suggested on the site I referenced, is to put into place a servlet filter. I'd like to know if I'm missing anything - is there a better way to do this? We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out (especially when they demonstrate that you can get a URL from the app, email it to someone else, and have that person magically bypass authentication and assume the role of the other user - of course as long as the session is still valid). We are comfortable saying that in order to use our application you need to have cookies enabled, so I'm making the assumption that if we disable the feature of putting JSESSIONID into the URLs, either through a nice global switch or else a servlet filter, cookie-based session setting/tracking will still function just as we expect it. Finally, anyone know why this isn't already in the servlet spec? Seems like with more and more concern over web application security that this would be something the spec should address? Thanks, Scott . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited.
