8.0->8.5 migration - digests
Just started testing a migration from 8.0 to 8.5. I'm was using digested passwords with digest="sha-512" in my realm for manager and i noticed in the migration doc that it said the digest property was removed. Took me a little while to figure out that this was replaced with the CredentialHandler. Might to nice to see a little blurb after the notice to say, this is replaced by CredentialHandler. See https://tomcat.apache.org/tomcat-8.5-doc/config/credentialhandler.html -Tony
Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33
On 16/05/2016 12:46, Venkata Reddy P wrote: > Many Thanks Again. Can you point me the ajp documentation to understand > different protocol(BIO, NIO,APR,..) implementations? The AJP implementation is the same for all of them. All the individual implementations do is plug in the appropriate Endpoint. You may want to take a look at the various Endpoint implementations in org.apache.tomcat.util.net Mark > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, May 16, 2016 5:13 PM > To: Tomcat Users List > Subject: Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33 > > On 16/05/2016 07:25, Venkata Reddy P wrote: >> Hi, >> >> >> >> Many Thanks Mark. This is a more of POC release planned for jun-1st week, >> will give a try with the existing stable release and thanks for suggesting >> the 8.5.x. >> >> >> >> 1) As you said, I can see AjpProtocol class as the BIO connector. If I >> create a customized class SslEnabledBioAjpProtocol extends AjpProtocol, then >> is the below configuration correct? >> >> > protocol="org.apache.coyote.ajp.SslEnabledBioAjpProtocol" >> redirectPort="8443" /> > > BIO support has been removed in 8.5.x. I suggest you base your implementation > on the NIO connector. > > protocol is the correct attribute to use to configure it. > > >> 2) In tomcat6, there http connector attribute to define the customized >> classname using attribute "sSLImplementation". >> >> > >> sSLImplementation=" >> org.apache.tomcat.util.net.jsse.Tomcat6SSLImplementation" >> >> scheme="https" secure="true" /> >> >> is it a still valid attribute in tomcat7.x/tomcat8.x? > > It still exists but you should not need to set it unless you are using some > form of custom TLS implementation. Also, I suspect the API for such a class > is version specific. > > 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat6.0.43 ajp connector migration to tomcat8.0.33
Many Thanks Again. Can you point me the ajp documentation to understand different protocol(BIO, NIO,APR,..) implementations? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, May 16, 2016 5:13 PM To: Tomcat Users List Subject: Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33 On 16/05/2016 07:25, Venkata Reddy P wrote: > Hi, > > > > Many Thanks Mark. This is a more of POC release planned for jun-1st week, > will give a try with the existing stable release and thanks for suggesting > the 8.5.x. > > > > 1) As you said, I can see AjpProtocol class as the BIO connector. If I > create a customized class SslEnabledBioAjpProtocol extends AjpProtocol, then > is the below configuration correct? > > protocol="org.apache.coyote.ajp.SslEnabledBioAjpProtocol" > redirectPort="8443" /> BIO support has been removed in 8.5.x. I suggest you base your implementation on the NIO connector. protocol is the correct attribute to use to configure it. > 2) In tomcat6, there http connector attribute to define the customized > classname using attribute "sSLImplementation". > > > sSLImplementation=" > org.apache.tomcat.util.net.jsse.Tomcat6SSLImplementation" > > scheme="https" secure="true" /> > > is it a still valid attribute in tomcat7.x/tomcat8.x? It still exists but you should not need to set it unless you are using some form of custom TLS implementation. Also, I suspect the API for such a class is version specific. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33
On 16/05/2016 07:25, Venkata Reddy P wrote: > Hi, > > > > Many Thanks Mark. This is a more of POC release planned for jun-1st week, > will give a try with the existing stable release and thanks for suggesting > the 8.5.x. > > > > 1) As you said, I can see AjpProtocol class as the BIO connector. If I > create a customized class SslEnabledBioAjpProtocol extends AjpProtocol, then > is the below configuration correct? > > protocol="org.apache.coyote.ajp.SslEnabledBioAjpProtocol" redirectPort="8443" > /> BIO support has been removed in 8.5.x. I suggest you base your implementation on the NIO connector. protocol is the correct attribute to use to configure it. > 2) In tomcat6, there http connector attribute to define the customized > classname using attribute "sSLImplementation". > > > sSLImplementation=" > org.apache.tomcat.util.net.jsse.Tomcat6SSLImplementation" > > scheme="https" secure="true" /> > > is it a still valid attribute in tomcat7.x/tomcat8.x? It still exists but you should not need to set it unless you are using some form of custom TLS implementation. Also, I suspect the API for such a class is version specific. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat6.0.43 ajp connector migration to tomcat8.0.33
Hi, Many Thanks Mark. This is a more of POC release planned for jun-1st week, will give a try with the existing stable release and thanks for suggesting the 8.5.x. 1) As you said, I can see AjpProtocol class as the BIO connector. If I create a customized class SslEnabledBioAjpProtocol extends AjpProtocol, then is the below configuration correct? 2) In tomcat6, there http connector attribute to define the customized classname using attribute "sSLImplementation". is it a still valid attribute in tomcat7.x/tomcat8.x? Thanks Venkata -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: 14 May 2016 00:04 To: Tomcat Users List Subject: Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33 On 13/05/2016 17:55, Venkata Reddy P wrote: > Existing implementation:- > > In tomcat6.0.43 version, I have enabled the ssl on AJP connector by > following the below steps > > 1) I did override the class "org.apache.jk.common.ChannelSocket" to > "AjpSslChannelSocket extends ChannelSocket " to enable ssl on ajp port. Tomcat does not support, and has never supported, AJP with TLS. AjpSslChannelSocket must be a custom implementation. > 2) This overridden "AjpSslChannelSocket" class I have configured in > server.xml file as below. > > class.channelSocket=" org.apache.jk.common. AjpSslChannelSocket " > enableLookups="false" maxThreads="150" port="8009" > protocol="AJP/1.3" tomcatAuthentication="false"/> > > I believe, it is a AJP java connector(ChannelSocket) implementation which > comes with tomcat6.0.43. am I correct? No. See above. > what kind of ajp connector implementation on class > “org.apache.jk.common.ChannelSocket” (APR,NIO,…)? BIO. > Migration to:- > > Currently I have to do the same on tomcat8.0.33 version to replicate the > above implemention to enable ssl on AJP port. That isn't going to be possible unless you write some custom code. > 1) When I look at the tomcat8.0.33 source code, I don’t find any > “org.apache.jk” package. > > Did “org.apache.jk” replaced with any package? Roughly, org.apache.coyote.ajp > 2) It looks like the ajp connector attribute (class.channelSocket) also > not available in tomcat8.0.33. > > Do we have any similar attribute to configure customized connector > implementation class? protocol > 3) Finally the class “ChannelSocket” is also missing in tomcat8.0.33. > > What class has to be customized in tomcat8.0.33 to enable ssl on ajp port > similar to above mentioned tomcat6.0.43 implementation? Given that 8.0.x will be replaced by 8.5.x fairly soon (within 3-4 months I should think) and that their is a major refactoring of the connector code between 8.0.x and 8.5.x you should be looking at the 8.5.x code. Look at the class hierarchy for AbstractAjpProtocol. You'll probably need to extend and override one of its sub-classes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
Re: tomcat6.0.43 ajp connector migration to tomcat8.0.33
On 13/05/2016 17:55, Venkata Reddy P wrote: > Existing implementation:- > > In tomcat6.0.43 version, I have enabled the ssl on AJP connector by following > the below steps > > 1) I did override the class "org.apache.jk.common.ChannelSocket" to > "AjpSslChannelSocket extends ChannelSocket " to enable ssl on ajp port. Tomcat does not support, and has never supported, AJP with TLS. AjpSslChannelSocket must be a custom implementation. > 2) This overridden "AjpSslChannelSocket" class I have configured in > server.xml file as below. > > class.channelSocket=" org.apache.jk.common. AjpSslChannelSocket " > enableLookups="false" maxThreads="150" port="8009" > protocol="AJP/1.3" tomcatAuthentication="false"/> > > I believe, it is a AJP java connector(ChannelSocket) implementation which > comes with tomcat6.0.43. am I correct? No. See above. > what kind of ajp connector implementation on class > “org.apache.jk.common.ChannelSocket” (APR,NIO,…)? BIO. > Migration to:- > > Currently I have to do the same on tomcat8.0.33 version to replicate the > above implemention to enable ssl on AJP port. That isn't going to be possible unless you write some custom code. > 1) When I look at the tomcat8.0.33 source code, I don’t find any > “org.apache.jk” package. > > Did “org.apache.jk” replaced with any package? Roughly, org.apache.coyote.ajp > 2) It looks like the ajp connector attribute (class.channelSocket) also > not available in tomcat8.0.33. > > Do we have any similar attribute to configure customized connector > implementation class? protocol > 3) Finally the class “ChannelSocket” is also missing in tomcat8.0.33. > > What class has to be customized in tomcat8.0.33 to enable ssl on ajp port > similar to above mentioned tomcat6.0.43 implementation? Given that 8.0.x will be replaced by 8.5.x fairly soon (within 3-4 months I should think) and that their is a major refactoring of the connector code between 8.0.x and 8.5.x you should be looking at the 8.5.x code. Look at the class hierarchy for AbstractAjpProtocol. You'll probably need to extend and override one of its sub-classes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat6.0.43 ajp connector migration to tomcat8.0.33
Hi, Can anyone please help me on this? Existing implementation:- In tomcat6.0.43 version, I have enabled the ssl on AJP connector by following the below steps 1) I did override the class "org.apache.jk.common.ChannelSocket" to "AjpSslChannelSocket extends ChannelSocket " to enable ssl on ajp port. 2) This overridden "AjpSslChannelSocket" class I have configured in server.xml file as below. I believe, it is a AJP java connector(ChannelSocket) implementation which comes with tomcat6.0.43. am I correct? what kind of ajp connector implementation on class “org.apache.jk.common.ChannelSocket” (APR,NIO,…)? Migration to:- Currently I have to do the same on tomcat8.0.33 version to replicate the above implemention to enable ssl on AJP port. 1) When I look at the tomcat8.0.33 source code, I don’t find any “org.apache.jk” package. Did “org.apache.jk” replaced with any package? 2) It looks like the ajp connector attribute (class.channelSocket) also not available in tomcat8.0.33. Do we have any similar attribute to configure customized connector implementation class? 3) Finally the class “ChannelSocket” is also missing in tomcat8.0.33. What class has to be customized in tomcat8.0.33 to enable ssl on ajp port similar to above mentioned tomcat6.0.43 implementation? Much appreciated, please advise me. Thank Venkata
Re: Tomcat 5.0.xx migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uzair, On 2/9/16 1:11 PM, uzair rashid wrote: > Most of our business is running Tomcat 7.x.xx or later. But, we > have a business function of ours that is using Tomcat 5.0.xx. > Unfortunately, this is causing a lot of issues in terms of > vulnerability remediation. You should definitely upgrade anything running Tomcat 5.x to something later. If possible, Tomcat 8.x would be preferable. > Apache Tomcat Servlet Host Manager Servlet Cross-Site Scripting > Vulnerability Don't deploy the host manager: no vulnerability at any Tomcat level. > Apache Tomcat Information Disclosure Vulnerability > > Apache Tomcat Accept-Language Cross-Site Scripting Vulnerability Though unspecified, these will have no workaround I know of. > Apache Tomcat JavaDoc Spoofing Vulnerability This is not a vulnerability in Tomcat itself, but the (Javadoc) documentation. Nobody should really have to worry about this, unless you host a copy of the javadoc somewhere in your own environment. > Apache Tomcat 4, 5 and 6 Examples Web Application Multiple > Cross-Site Scripting Vulnerabilities > > Apache Tomcat 4 and 5 Cross-Site Scripting Vulnerability in > Calender Application in JSP Examples > > Apache Tomcat 5 Cross-Site Scripting in implicit-objects.jsp of > "Examples" Application Don't deploy the examples: no vulnerability at any Tomcat level. > Apache Tomcat Multiple Content Length Headers Information > Disclosure Vulnerability Not sure. > Apache Tomcat Multiple Cross-Site Scripting Vulnerabilities in > Manager and Host Manager Web Applications Don't deploy the host manager. If you need to deploy the manager application, make sure you secure it and make sure your web-based users know not to click on emailed links that take them directly into the manager application. > Apache Tomcat 4 and 5 Multiple Cross-Site Scripting > Vulnerabilities These are usually issues with an application (e.g. Examples) and not the server. > The above is what were are experiencing and we are running Crystal > Report as well. What does Crystal Reports have to do with anything? > Could someone please guide me in the most efficient way to > upgrade? http://tomcat.apache.org/migration.html There are no migration guides from 5.0 -> 8.0, but if you read them all, you'll know what issues you might face. > My thought process is 5.0.xx to 5.5 then migration to 6 or 7? There is no particular reason to upgrade each release one at a time. You can go from 5.x to 8.x all at once. > We are running windows 2003. I’m not even sure if it will support > it? If Java runs on it, Tomcat will run on it (assuming you have enough memory to run your own application). > I am unable to find any process documents or guidance on how to go > about the upgrade process and which version could help us in > vulnerability remediation. Could someone please help me? This is > extremely time sensitive to our business needs. See the migration guide(s) above. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAla6MuMACgkQ9CaO5/Lv0PDjNACfXUgItmPkp4yjaC1R1sZB53c3 ONIAoIOIs9ETF5f6R5WXLdwtefPdVrIO =61j9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.0.xx migration
Hello Experts: Most of our business is running Tomcat 7.x.xx or later. But, we have a business function of ours that is using Tomcat 5.0.xx. Unfortunately, this is causing a lot of issues in terms of vulnerability remediation. Apache Tomcat Servlet Host Manager Servlet Cross-Site Scripting Vulnerability Apache Tomcat Information Disclosure Vulnerability Apache Tomcat Accept-Language Cross-Site Scripting Vulnerability Apache Tomcat JavaDoc Spoofing Vulnerability Apache Tomcat 4, 5 and 6 Examples Web Application Multiple Cross-Site Scripting Vulnerabilities Apache Tomcat 4 and 5 Cross-Site Scripting Vulnerability in Calender Application in JSP Examples Apache Tomcat 5 Cross-Site Scripting in implicit-objects.jsp of "Examples" Application Apache Tomcat Multiple Content Length Headers Information Disclosure Vulnerability Apache Tomcat Multiple Cross-Site Scripting Vulnerabilities in Manager and Host Manager Web Applications Apache Tomcat 4 and 5 Multiple Cross-Site Scripting Vulnerabilities The above is what were are experiencing and we are running Crystal Report as well. Could someone please guide me in the most efficient way to upgrade? My thought process is 5.0.xx to 5.5 then migration to 6 or 7? We are running windows 2003. I’m not even sure if it will support it? I am unable to find any process documents or guidance on how to go about the upgrade process and which version could help us in vulnerability remediation. Could someone please help me? This is extremely time sensitive to our business needs. Cheers!
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Indeed, it seems a little bit strange and certainly you are right. I think the main reason is that it would be more complicated to maintain the system with regular security updates. It has to be a manual process. Somehow or other we need a working solution. It is also an option to fix DigestAuthenticator class in tomcat6 to split digest authentication header like it is done in tomcat7, because this is the real cause of the problem - the regular expression submitted to the split method cannot properly handle unquoted parameters at the end of the auth header line. Thank you for your constructive input. -sascha Von: Christopher Schultz [ch...@christopherschultz.net] Gesendet: Dienstag, 17. März 2015 17:10 Bis: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/17/15 11:12 AM, Rainer Jung wrote: Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. +1 I find it hard to believe that you (or your NOC) would be willing to upgrade the OS and the web server to use an alternative solution, but not willing to upgrade to a newer version of single, specialized module for the web server. Note that you don't have to have a compiler on the target system; you just need to be able to cross-compile to that test system (or do what I do and have a spare server with identical architecture, etc. available for module builds). Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. +1 Building is trivial. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFHcAAoJEBzwKT+lPKRYOQAQAJnIlsepWBvZlO438/zwXIYM WI0X3LspAUt1v1c0JOXagL5VUdZO68/euBV7rmoKaHvo11lEH5lFQ9M91unvRWer d7AQZoTc1+VQDcnBrGDzw6M7jQqlKf2Y7Jadlj9TfNm68cwCYFhpan1Wcv/XCMpy /1Q5j/gW77AdPNpAvtFGOXZ0HPbMpkC+ZpsfFjgpOrwUBPL195xpQXM5nJLoYpAa 7uR34FCAbIIR0Glho/IHqzadxrSBq3AEVZau1uiGi3t8BjuWcOfq85bMZ0dCGdl+ Hlj6wKaTpS6AJi9By5d0xbXkqu5wBY2qFgY6wNq/cHO/Js+svPPMtME7eUZiOPAY t2dUszkzqw0JOEqTN0I1gr0cGVOhJYbHMAdCHrb15FtWACeQVHVK7ikI0GJvKMG3 8EUIW21go3ID4jHBpexMC23QZDKfDTIhzx9Ec300lxRbjkfzpTCEvu3mM36w6y7+ fsRPPkpY0KqFe25nYw/DZCMS4KeAZ5dZSQa3sQSYgpozP71UrRZJw2+cqdALj29Q Ozru/eLGLAvJuOKbXgSMIBfEQugx8vTGzE60Db7e61thMPmyHXlHqi1+zKDnODej g6kbQtNDhak+0AfI2oFbmvHGz+hN8bAJa62hA/3jDKiYphxwH2JpJW4qmcs7HI91 qRp/u8yrAe8S/UAc+x+2 =95gA -END PGP SIGNATURE- - 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
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and- digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and- digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. Regards sascha -Ursprüngliche Nachricht- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Dienstag, 17. März 2015 15:00 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and - digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/17/15 11:12 AM, Rainer Jung wrote: Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. +1 I find it hard to believe that you (or your NOC) would be willing to upgrade the OS and the web server to use an alternative solution, but not willing to upgrade to a newer version of single, specialized module for the web server. Note that you don't have to have a compiler on the target system; you just need to be able to cross-compile to that test system (or do what I do and have a spare server with identical architecture, etc. available for module builds). Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. +1 Building is trivial. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFHcAAoJEBzwKT+lPKRYOQAQAJnIlsepWBvZlO438/zwXIYM WI0X3LspAUt1v1c0JOXagL5VUdZO68/euBV7rmoKaHvo11lEH5lFQ9M91unvRWer d7AQZoTc1+VQDcnBrGDzw6M7jQqlKf2Y7Jadlj9TfNm68cwCYFhpan1Wcv/XCMpy /1Q5j/gW77AdPNpAvtFGOXZ0HPbMpkC+ZpsfFjgpOrwUBPL195xpQXM5nJLoYpAa 7uR34FCAbIIR0Glho/IHqzadxrSBq3AEVZau1uiGi3t8BjuWcOfq85bMZ0dCGdl+ Hlj6wKaTpS6AJi9By5d0xbXkqu5wBY2qFgY6wNq/cHO/Js+svPPMtME7eUZiOPAY t2dUszkzqw0JOEqTN0I1gr0cGVOhJYbHMAdCHrb15FtWACeQVHVK7ikI0GJvKMG3 8EUIW21go3ID4jHBpexMC23QZDKfDTIhzx9Ec300lxRbjkfzpTCEvu3mM36w6y7+ fsRPPkpY0KqFe25nYw/DZCMS4KeAZ5dZSQa3sQSYgpozP71UrRZJw2+cqdALj29Q Ozru/eLGLAvJuOKbXgSMIBfEQugx8vTGzE60Db7e61thMPmyHXlHqi1+zKDnODej g6kbQtNDhak+0AfI2oFbmvHGz+hN8bAJa62hA/3jDKiYphxwH2JpJW4qmcs7HI91 qRp/u8yrAe8S/UAc+x+2 =95gA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAwIvAAoJEBzwKT+lPKRYOc4P/2+nCQm+qwhJpz5hxEFaxebx Y34D5ZF9D4OEdGeaRKNj+mYfDPHDpkbI2Ks3bewf1esnIlA96F4oXPdkXMc2Gn/F 1ETNN78g5ulquya/AYmNjVq1fAtjoaiiisKpv5iM0DJIVA0EdH3T8yUoA9t4MwPc ndnt89eFfCeFi3FcJCP6EE1TFib+qWsBsAAwSP1J6JttzCDHviDjLt4aTABwBhXf AAPzD2kLZm69FjphNOLTqaFr0Ec8+uSCGjK+UuC8AgaXYScnxBg92Y80lgqPV77m 7A6TOIVx1O8e1/6Wj1JCk4YrTrjB+90nShkATgnXBy4/DO/jEtFP7QyRovCYbuwf 9kUdl/6IovpR4j4OyYQ8EUPQqXeT3fpKZDk4XiW3iqdRX+zSyBvi95Igd+H9QfEH gK1cMmeXQEdEY0XlgXU82iVNyzbl+JWma8QswiSnXEdYdxPUTKuaZkpx2W/757ID GFlYa87tbHQbfbSnBAx5SqaoIVKqZaob7fnVkD32b0uiaCqw7nxhuB8q/QeiY9e8 8lUoTrccj5Uo+5liBp5/0ztSjSkdIZmUQdLnGhaGDBA9t1zNeyOfbNSXQjHKeEJf l/tl7GNgQ+56pGrlwmuJLPQRTyjwcx+6B9SmpUhJly4YaxMS13Tk77azwVnjCEV4 RQu1uvmH9wOhNCocyyAe =TebI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID is
generated after a successful authentication. The first http response (401 with
Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests resulting
from the digest authentication are sent to the same tomcat instance. In Tomcat
6 it was no problem because nonces were not cached or rather unknown nonces did
not force a re-authentication like it is done in the DigestAuthenticator of
Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request with
authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID
is generated after a successful authentication. The first http response (401
with Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Most load-balancers have various options for doing this that don't
depend on the back-end server at all.
Mark
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests
resulting from the digest authentication are sent to the same tomcat
instance. In Tomcat 6 it was no problem because nonces were not cached or
rather unknown nonces did not force a re-authentication like it is done in
the DigestAuthenticator of Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped
out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request
with authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Sascha, you can configure source address stickyness as well as
destination address stickyness, both will provide the same result
which will work for you.
2015-03-12 18:13 GMT+01:00 Mark Thomas ma...@apache.org:
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID
is generated after a successful authentication. The first http response (401
with Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Most load-balancers have various options for doing this that don't
depend on the back-end server at all.
Mark
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests
resulting from the digest authentication are sent to the same tomcat
instance. In Tomcat 6 it was no problem because nonces were not cached or
rather unknown nonces did not force a re-authentication like it is done in
the DigestAuthenticator of Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped
out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request
with authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
-
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
Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests resulting
from the digest authentication are sent to the same tomcat instance. In Tomcat
6 it was no problem because nonces were not cached or rather unknown nonces did
not force a re-authentication like it is done in the DigestAuthenticator of
Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request with
authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
Re: TomcatSasJAASRealm issue while Tomcat6 to Tomcat7 migration
2015-02-06 20:05 GMT+03:00 Mahato, Jitendra N.
jitendra.n.mah...@supervalu.com:
Hi All,
I am facing issue while migrating my application from Tomcat 6 to Tomcat 7.
Current Version:- Tomcat 6.0.18, Java 1.6.0.30
Upgrade Version:- Tomcat 7.0.50, Java 1.7.0.51
Please help me to resolve the below issue.
Issue after migration:- Not able to login into the application.
Stage log errors:-
Jan 16, 2015 9:10:39 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'maxSpareThreads' to '64' did not find a matching property.
Broken configuration. There is no such attribute on Connector.
Jan 16, 2015 9:10:39 AM org.apache.tomcat.util.digester.Digester endElement
WARNING: No rules found matching 'Server/Service/Engine/Loader'.
Broken configuration. There is no support for a Loader element in an Engine.
Jan 16, 2015 9:10:39 AM org.apache.tomcat.util.digester.Digester startElement
SEVERE: Begin event threw error
java.lang.NoClassDefFoundError: org/apache/catalina/util/StringManager
at
com.shaws.framework.security.realm.TomcatSasJAASRealm.clinit(TomcatSasJAASRealm.java:212)
The someone's TomcatSasJAASRealm is not designed for Tomcat 7. It
depends on an internal API that was changed / moved.
As Mark mentioned, the Migration guide is a must-read.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
TomcatSasJAASRealm issue while Tomcat6 to Tomcat7 migration
Hi All,
I am facing issue while migrating my application from Tomcat 6 to Tomcat 7.
Current Version:- Tomcat 6.0.18, Java 1.6.0.30
Upgrade Version:- Tomcat 7.0.50, Java 1.7.0.51
Please help me to resolve the below issue.
Issue after migration:- Not able to login into the application.
Stage log errors:-
Jan 16, 2015 9:10:39 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'maxSpareThreads' to '64' did not find a matching property.
Jan 16, 2015 9:10:39 AM org.apache.tomcat.util.digester.Digester endElement
WARNING: No rules found matching 'Server/Service/Engine/Loader'.
Jan 16, 2015 9:10:39 AM org.apache.tomcat.util.digester.Digester startElement
SEVERE: Begin event threw error
java.lang.NoClassDefFoundError: org/apache/catalina/util/StringManager
at
com.shaws.framework.security.realm.TomcatSasJAASRealm.clinit(TomcatSasJAASRealm.java:212)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at
org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:145)
at
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
at
com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561)
at org.apache.catalina.startup.Catalina.load(Catalina.java:616)
at org.apache.catalina.startup.Catalina.load(Catalina.java:664)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
Caused by: java.lang.ClassNotFoundException:
org.apache.catalina.util.StringManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
I configured in my dev environment and getting the below error.
Log errors in dev.
Feb 6, 2015 8:21:51 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'maxSpareThreads' to '64' did not find a matching property.
Feb 6, 2015 8:21:51 PM org.apache.tomcat.util.digester.Digester endElement
WARNING: No rules found matching 'Server/Service/Engine/Loader'.
Feb 6, 2015 8:21:51 PM org.apache.tomcat.util.digester.Digester startElement
SEVERE: Begin event threw error
java.lang.VerifyError: class
com.shaws.framework.security.realm.TomcatSasJAASRealm overrides final method
start.()V
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source
Re: TomcatSasJAASRealm issue while Tomcat6 to Tomcat7 migration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/6/2015 9:05 AM, Mahato, Jitendra N. wrote:
Hi All,
I am facing issue while migrating my application from Tomcat 6 to
Tomcat 7. Current Version:- Tomcat 6.0.18, Java 1.6.0.30 Upgrade
Version:- Tomcat 7.0.50, Java 1.7.0.51
Please help me to resolve the below issue.
Issue after migration:- Not able to login into the application.
Stage log errors:-
Jan 16, 2015 9:10:39 AM
org.apache.catalina.startup.SetAllPropertiesRule begin WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'maxSpareThreads' to '64' did not find a matching property. Jan 16,
2015 9:10:39 AM org.apache.tomcat.util.digester.Digester
endElement WARNING: No rules found matching
'Server/Service/Engine/Loader'. Jan 16, 2015 9:10:39 AM
org.apache.tomcat.util.digester.Digester startElement SEVERE: Begin
event threw error java.lang.NoClassDefFoundError:
org/apache/catalina/util/StringManager at
com.shaws.framework.security.realm.TomcatSasJAASRealm.clinit(TomcatSasJAASRealm.java:212)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374) at
org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:145)
at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
at
com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561)
at org.apache.catalina.startup.Catalina.load(Catalina.java:616) at
org.apache.catalina.startup.Catalina.load(Catalina.java:664) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606) at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
Caused by: java.lang.ClassNotFoundException:
org.apache.catalina.util.StringManager at
java.net.URLClassLoader$1.run(URLClassLoader.java:366) at
java.net.URLClassLoader$1.run(URLClassLoader.java:355) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:354) at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) at
java.lang.ClassLoader.loadClass(ClassLoader.java:358)
I configured in my dev environment and getting the below error. Log
errors in dev.
Feb 6, 2015 8:21:51 PM
org.apache.catalina.startup.SetAllPropertiesRule begin WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'maxSpareThreads' to '64' did not find a matching property. Feb 6,
2015 8:21:51 PM org.apache.tomcat.util.digester.Digester
endElement WARNING: No rules found matching
'Server/Service/Engine/Loader'. Feb 6, 2015 8:21:51 PM
org.apache.tomcat.util.digester.Digester startElement SEVERE: Begin
event threw error java.lang.VerifyError: class
com.shaws.framework.security.realm.TomcatSasJAASRealm overrides
final method start.()V at java.lang.ClassLoader.defineClass1(Native
Method) at java.lang.ClassLoader.defineClass(Unknown Source) at
java.security.SecureClassLoader.defineClass(Unknown Source) at
java.net.URLClassLoader.defineClass(Unknown Source) at
java.net.URLClassLoader.access$000(Unknown Source) at
java.net.URLClassLoader$1.run(Unknown Source
Re: Struts 2 /Glassfish to Tomcat migration
Thanks Chris. I was able to fix the issue. On Fri, Oct 3, 2014 at 10:52 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 10/3/14 8:02 PM, Kiran Badi wrote: Thanks Chris for replying.I did resolve the 404 issue,it's error on my part. One of view jsp was in incorrect folder so it was throwing 404 error.Fixed it and now it works fine. I do not recall as how I installed this tomcat probably I downloaded the zip file and then integrated that installation with netbeans. The Tomcat server zip distribution does not contain any .dll files. You either downloaded and installed the .dll files yourself or you used the Windows Installer package which includes these libraries. x86-64 do I need to download this file from apache tomcat site ? how do I use this file ? edit the environment variables ? You should have several .dll files if you have a single one. Take a look at them to determine which is the correct one for your architecture and put it in whatever your java.library.path is, named tcnative-1.dll. Or, if you don't want or need the APR connector, then disable the APRLifecycleListener in server.xml and the JVM won't even try to load it. - -chris On Thu, Oct 2, 2014 at 10:38 PM, Christopher Schultz ch...@christopherschultz.net wrote: Kiran, On 10/2/14 9:59 PM, Kiran Badi wrote: I am migration my glassfish struts 2 based application to Tomcat 7.055. I am coming across 2 issues, first one is below exception while starting Tomcat java.lang.UnsatisfiedLinkError: C:\Apache Software Foundation\apache-tomcat-7.0.55\bin\tcnative-1.dll: Can't load IA 64-bit .dll on a AMD 64-bit platform You have the IA-64 library in your path, and you need the x86-64 library instead. How did you install Tomcat? If you used the binary installer, it should have correctly detected your architecture and used the correct library. If you installed it manually, you should have a selection of tcnative .dll files. fine the x86-64 one and use that. these are java information, Using CATALINA_BASE: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_HOME: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_TMPDIR: C:\Apache Software Foundation\apache-tomcat-7.0.55\temp Using JRE_HOME: C:\Program Files\Java\jdk1.7.0_13 Though the server starts and I can access the home page, but it seems like struts.xml file is getting ignored and i am getting 404 for all jsp which are under web-inf. The inability to start the APR connector won't have any effect on this. How are you trying to access your .jsp files within WEB-INF? Via a direct URL or some kind of internal forward from another URL? Is their any migration guide from glassfish 4x to Tomcat ? You shouldn't have to do too much to migrate, as long as you don't have anything GlassFish-specific in your webapp. You should be able to take your existing WAR file and drop it into Tomcat's webapps/ directory. That should get you 90% of the way. If you use JNDI-based resources, you'll have additional configuration, but I won't get into that unless you actually need it. I was thinking that copying struts.xml to config directory and setting dispatcher servlet should be sufficient. I am missing anything here. What is config directory and how did you set [the] dispatcher servlet? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUL2DnAAoJEBzwKT+lPKRYvwYP/jLLJRkE2jmiTwfyvMZZ9M/J a/E6rgdVFzIZnjxx2T1FG6D+Hd95RXP7rxdfdxlJdZurmvjsC/4lISiZlrSD1FUw NQPUS2A8EkfWNsN8PbaAGFAOWZp/6tkET11wYHGvTJ664MX9ENdyjgK5dCx4yIDn QbQHKDrEa472hpkIMZms1V6yhgU8dr+I22Sf12oIy8WcYc5i5T4e9RSXB7N6nh1R WYZktR9VpKK6Mrg4R108Oztyc61YKelYNa/bmP7uhW0BGX+QItP4htC8KYZVVROi cSkoQvTRvO0sKmCdUXnCGStpEPGKcFq711wxB0k4+ToLgtAJzMC8eXBkx1UTNhU2 VwuHiZxP4ISh9MV0A7RSW+nTFbG5QMgClnj/eLa448R3bbukXmGDkCkzWyg8JKlZ mRAeS7xXVt2daaSXz7t4bX2hn+T88TRHgvgyVxKhieVqHQsCastifpL8cmHdI+Dn gp7Z0qcr6gGbFUlnmXx7VqazFP58CPWaGLPWB2YMEt7s7r72h0tCgqxZFQFnhh8f pELvVO3DlAtMWOeJj3OzBt/Z9xHN+iCcvI52bcQGvUhnge1R6g9DksfkBX1j7bOq mIsrXKoKFdLJQ6rC28eFmwV/+LnOaDMEsPOabvgaIUBo+zoKn7a4ZQDtErVBZVkw LNEuu2cPUwTMErBoVG7m =YdbI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Struts 2 /Glassfish to Tomcat migration
Thanks Chris for replying.I did resolve the 404 issue,it's error on my part. One of view jsp was in incorrect folder so it was throwing 404 error.Fixed it and now it works fine. I do not recall as how I installed this tomcat probably I downloaded the zip file and then integrated that installation with netbeans. x86-64 do I need to download this file from apache tomcat site ? how do I use this file ? edit the environment variables ? On Thu, Oct 2, 2014 at 10:38 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 10/2/14 9:59 PM, Kiran Badi wrote: I am migration my glassfish struts 2 based application to Tomcat 7.055. I am coming across 2 issues, first one is below exception while starting Tomcat java.lang.UnsatisfiedLinkError: C:\Apache Software Foundation\apache-tomcat-7.0.55\bin\tcnative-1.dll: Can't load IA 64-bit .dll on a AMD 64-bit platform You have the IA-64 library in your path, and you need the x86-64 library instead. How did you install Tomcat? If you used the binary installer, it should have correctly detected your architecture and used the correct library. If you installed it manually, you should have a selection of tcnative .dll files. fine the x86-64 one and use that. these are java information, Using CATALINA_BASE: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_HOME: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_TMPDIR: C:\Apache Software Foundation\apache-tomcat-7.0.55\temp Using JRE_HOME:C:\Program Files\Java\jdk1.7.0_13 Though the server starts and I can access the home page, but it seems like struts.xml file is getting ignored and i am getting 404 for all jsp which are under web-inf. The inability to start the APR connector won't have any effect on this. How are you trying to access your .jsp files within WEB-INF? Via a direct URL or some kind of internal forward from another URL? Is their any migration guide from glassfish 4x to Tomcat ? You shouldn't have to do too much to migrate, as long as you don't have anything GlassFish-specific in your webapp. You should be able to take your existing WAR file and drop it into Tomcat's webapps/ directory. That should get you 90% of the way. If you use JNDI-based resources, you'll have additional configuration, but I won't get into that unless you actually need it. I was thinking that copying struts.xml to config directory and setting dispatcher servlet should be sufficient. I am missing anything here. What is config directory and how did you set [the] dispatcher servlet? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJULgw0AAoJEBzwKT+lPKRYoI8P/2N1QNVZK1ZfvPqNNY2sALE0 4obJMM/vKtzDsKrJmJ+kaTfSAt1Cnd6fOP3VCFUYrfkKGWUjOfTczxN6c2RgvJbV R8Y9nwUhevgb2Y36slZ2Kda6g2XmxH5WR8PU/qEF8qRu+ZM7BSkKAkfUz+lrbrC2 a4MD02LmiQXaXEyxsFzOcW+Ig9iMUi4gpCA5hJw9SJtObedeW9rfQDrNJVpMd559 FFUdGE6hz2/+3JcTV+gYutYrS0sGuPrTL/WA+X7OYTdPheU6R9JmiK8OmLBA6COg aNBT6k/Bm29NgTQVAXATkomI7fBCV3HRYlIH7eA1oZgMPgSKf6PTdrfKaAvZZfz0 qxXl9dD7gXgssNN59CxxDu2xHlYv11RMN/vlVodpdWWHWkttetigpQi1wL3dDfJd uBzi8vl8DXVcs+44sZ+lPNa07VjHRxR8zElqTppQ9f500ozQN+5j18LYtOKefoOZ HmQ1lhs721hN5XzWP1xQRZGFNVg1fb0tBFVf/n2TT3n9DhiQhXpy029xKYkUBa9q Ch2iFzQN1HbLimBVuUlKx2fDjy8P6BWUfN0I1T9kSPLwZwtSZy8V0JuSuaOdkNby kQ6PQBV5CMQNdMNcNE5rIDUA66YyLOMXMYnN/pQaT5JIoeTJL0b2jVNweFGcdukp ANyaJNqtL6SuIS7DUmvE =QXr1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Struts 2 /Glassfish to Tomcat migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 10/3/14 8:02 PM, Kiran Badi wrote: Thanks Chris for replying.I did resolve the 404 issue,it's error on my part. One of view jsp was in incorrect folder so it was throwing 404 error.Fixed it and now it works fine. I do not recall as how I installed this tomcat probably I downloaded the zip file and then integrated that installation with netbeans. The Tomcat server zip distribution does not contain any .dll files. You either downloaded and installed the .dll files yourself or you used the Windows Installer package which includes these libraries. x86-64 do I need to download this file from apache tomcat site ? how do I use this file ? edit the environment variables ? You should have several .dll files if you have a single one. Take a look at them to determine which is the correct one for your architecture and put it in whatever your java.library.path is, named tcnative-1.dll. Or, if you don't want or need the APR connector, then disable the APRLifecycleListener in server.xml and the JVM won't even try to load it. - -chris On Thu, Oct 2, 2014 at 10:38 PM, Christopher Schultz ch...@christopherschultz.net wrote: Kiran, On 10/2/14 9:59 PM, Kiran Badi wrote: I am migration my glassfish struts 2 based application to Tomcat 7.055. I am coming across 2 issues, first one is below exception while starting Tomcat java.lang.UnsatisfiedLinkError: C:\Apache Software Foundation\apache-tomcat-7.0.55\bin\tcnative-1.dll: Can't load IA 64-bit .dll on a AMD 64-bit platform You have the IA-64 library in your path, and you need the x86-64 library instead. How did you install Tomcat? If you used the binary installer, it should have correctly detected your architecture and used the correct library. If you installed it manually, you should have a selection of tcnative .dll files. fine the x86-64 one and use that. these are java information, Using CATALINA_BASE: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_HOME: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_TMPDIR: C:\Apache Software Foundation\apache-tomcat-7.0.55\temp Using JRE_HOME: C:\Program Files\Java\jdk1.7.0_13 Though the server starts and I can access the home page, but it seems like struts.xml file is getting ignored and i am getting 404 for all jsp which are under web-inf. The inability to start the APR connector won't have any effect on this. How are you trying to access your .jsp files within WEB-INF? Via a direct URL or some kind of internal forward from another URL? Is their any migration guide from glassfish 4x to Tomcat ? You shouldn't have to do too much to migrate, as long as you don't have anything GlassFish-specific in your webapp. You should be able to take your existing WAR file and drop it into Tomcat's webapps/ directory. That should get you 90% of the way. If you use JNDI-based resources, you'll have additional configuration, but I won't get into that unless you actually need it. I was thinking that copying struts.xml to config directory and setting dispatcher servlet should be sufficient. I am missing anything here. What is config directory and how did you set [the] dispatcher servlet? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUL2DnAAoJEBzwKT+lPKRYvwYP/jLLJRkE2jmiTwfyvMZZ9M/J a/E6rgdVFzIZnjxx2T1FG6D+Hd95RXP7rxdfdxlJdZurmvjsC/4lISiZlrSD1FUw NQPUS2A8EkfWNsN8PbaAGFAOWZp/6tkET11wYHGvTJ664MX9ENdyjgK5dCx4yIDn QbQHKDrEa472hpkIMZms1V6yhgU8dr+I22Sf12oIy8WcYc5i5T4e9RSXB7N6nh1R WYZktR9VpKK6Mrg4R108Oztyc61YKelYNa/bmP7uhW0BGX+QItP4htC8KYZVVROi cSkoQvTRvO0sKmCdUXnCGStpEPGKcFq711wxB0k4+ToLgtAJzMC8eXBkx1UTNhU2 VwuHiZxP4ISh9MV0A7RSW+nTFbG5QMgClnj/eLa448R3bbukXmGDkCkzWyg8JKlZ mRAeS7xXVt2daaSXz7t4bX2hn+T88TRHgvgyVxKhieVqHQsCastifpL8cmHdI+Dn gp7Z0qcr6gGbFUlnmXx7VqazFP58CPWaGLPWB2YMEt7s7r72h0tCgqxZFQFnhh8f pELvVO3DlAtMWOeJj3OzBt/Z9xHN+iCcvI52bcQGvUhnge1R6g9DksfkBX1j7bOq mIsrXKoKFdLJQ6rC28eFmwV/+LnOaDMEsPOabvgaIUBo+zoKn7a4ZQDtErVBZVkw LNEuu2cPUwTMErBoVG7m =YdbI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Struts 2 /Glassfish to Tomcat migration
I am migration my glassfish struts 2 based application to Tomcat 7.055. I am coming across 2 issues, first one is below exception while starting Tomcat java.lang.UnsatisfiedLinkError: C:\Apache Software Foundation\apache-tomcat-7.0.55\bin\tcnative-1.dll: Can't load IA 64-bit .dll on a AMD 64-bit platform these are java information, Using CATALINA_BASE: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_HOME: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_TMPDIR: C:\Apache Software Foundation\apache-tomcat-7.0.55\temp Using JRE_HOME:C:\Program Files\Java\jdk1.7.0_13 Though the server starts and I can access the home page, but it seems like struts.xml file is getting ignored and i am getting 404 for all jsp which are under web-inf. Is their any migration guide from glassfish 4x to Tomcat ? I was thinking that copying struts.xml to config directory and setting dispatcher servlet should be sufficient.I am missing anything here.
Re: Struts 2 /Glassfish to Tomcat migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 10/2/14 9:59 PM, Kiran Badi wrote: I am migration my glassfish struts 2 based application to Tomcat 7.055. I am coming across 2 issues, first one is below exception while starting Tomcat java.lang.UnsatisfiedLinkError: C:\Apache Software Foundation\apache-tomcat-7.0.55\bin\tcnative-1.dll: Can't load IA 64-bit .dll on a AMD 64-bit platform You have the IA-64 library in your path, and you need the x86-64 library instead. How did you install Tomcat? If you used the binary installer, it should have correctly detected your architecture and used the correct library. If you installed it manually, you should have a selection of tcnative .dll files. fine the x86-64 one and use that. these are java information, Using CATALINA_BASE: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_HOME: C:\Apache Software Foundation\apache-tomcat-7.0.55 Using CATALINA_TMPDIR: C:\Apache Software Foundation\apache-tomcat-7.0.55\temp Using JRE_HOME:C:\Program Files\Java\jdk1.7.0_13 Though the server starts and I can access the home page, but it seems like struts.xml file is getting ignored and i am getting 404 for all jsp which are under web-inf. The inability to start the APR connector won't have any effect on this. How are you trying to access your .jsp files within WEB-INF? Via a direct URL or some kind of internal forward from another URL? Is their any migration guide from glassfish 4x to Tomcat ? You shouldn't have to do too much to migrate, as long as you don't have anything GlassFish-specific in your webapp. You should be able to take your existing WAR file and drop it into Tomcat's webapps/ directory. That should get you 90% of the way. If you use JNDI-based resources, you'll have additional configuration, but I won't get into that unless you actually need it. I was thinking that copying struts.xml to config directory and setting dispatcher servlet should be sufficient. I am missing anything here. What is config directory and how did you set [the] dispatcher servlet? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJULgw0AAoJEBzwKT+lPKRYoI8P/2N1QNVZK1ZfvPqNNY2sALE0 4obJMM/vKtzDsKrJmJ+kaTfSAt1Cnd6fOP3VCFUYrfkKGWUjOfTczxN6c2RgvJbV R8Y9nwUhevgb2Y36slZ2Kda6g2XmxH5WR8PU/qEF8qRu+ZM7BSkKAkfUz+lrbrC2 a4MD02LmiQXaXEyxsFzOcW+Ig9iMUi4gpCA5hJw9SJtObedeW9rfQDrNJVpMd559 FFUdGE6hz2/+3JcTV+gYutYrS0sGuPrTL/WA+X7OYTdPheU6R9JmiK8OmLBA6COg aNBT6k/Bm29NgTQVAXATkomI7fBCV3HRYlIH7eA1oZgMPgSKf6PTdrfKaAvZZfz0 qxXl9dD7gXgssNN59CxxDu2xHlYv11RMN/vlVodpdWWHWkttetigpQi1wL3dDfJd uBzi8vl8DXVcs+44sZ+lPNa07VjHRxR8zElqTppQ9f500ozQN+5j18LYtOKefoOZ HmQ1lhs721hN5XzWP1xQRZGFNVg1fb0tBFVf/n2TT3n9DhiQhXpy029xKYkUBa9q Ch2iFzQN1HbLimBVuUlKx2fDjy8P6BWUfN0I1T9kSPLwZwtSZy8V0JuSuaOdkNby kQ6PQBV5CMQNdMNcNE5rIDUA66YyLOMXMYnN/pQaT5JIoeTJL0b2jVNweFGcdukp ANyaJNqtL6SuIS7DUmvE =QXr1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Server Migration question Solaris 9 to Solaris 10
Hello all, I'm in the middle of a hardware upgrade. The application expert has on our project work list copy /opt/tomcat/* from old machine to new machine. The old machine is a Sun V240, running Solaris 9. The New machine is an Oracle (Sun) T4 server running Solaris 10. Tomcat version is Tomcat 6. Can we do this? will it run?It seems to be a Java based product and it stands to reason that if the JDK is the same it would be fine. I'm worried about any C code compiled for Solaris 9. Why should we NOT do this ? thanks, Eric Clifford Sr. Systems Engineer, Unix/Linux 412-328-5477 412-288-5472 desk thanks, Eric Clifford Sr. Systems Engineer, Unix/Linux 412-328-5477 412-288-5472 desk - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -
Re: Server Migration question Solaris 9 to Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric, On 9/25/13 5:18 PM, Eric Clifford wrote: I'm in the middle of a hardware upgrade. The application expert has on our project work list copy /opt/tomcat/* from old machine to new machine. The old machine is a Sun V240, running Solaris 9. The New machine is an Oracle (Sun) T4 server running Solaris 10. Tomcat version is Tomcat 6. Can we do this? Sure. will it run? Probably: Tomcat was likely installed from a tarball and therefore is entirely self-contained. You may have some startup scripts under /etc that you'll need to move to get everything back the way it was, but Tomcat itself should be entirely under /opt/tomcat (assuming that's where it's been installed). It seems to be a Java based product and it stands to reason that if the JDK is the same it would be fine. That's a reasonable assumption. I'm worried about any C code compiled for Solaris 9. Unless you are using APR/tcnative, there are no native components to Tomcat. You may have some of your own, but you'll have to check that our yourself. Why should we NOT do this ? One reason: the opportunity to upgrade Tomcat during this process. IF you aren't on Tomcat 6.0.latest, you really should upgrade. If you are feeling confident, consider going all the way up to 7.0.latest. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQ3d0AAoJEBzwKT+lPKRYHvAP/1TMDnoWR78lPMYGIG/KNaol +ojngc+x9JLDHYQy/tKHuKexuNaaQsspyjzPmh7ICyZmes2lohW4FwPdK+MLRNeA TIjMlvfjnvTL0ykraX+MUzjJurC/XY2nV1yaw4ZlLsvD9gc52ikfeiTCUOGIrR09 97UKt3oZp2XpKj74S1tXBbglo6WnNv6SHNXfjTUgzxz+NIYagdmJNOpeh/31PODa PfW9Q1NHNNsz1C5l6NoVH9xnmYcikw3U4ary2HJoIq5c39Ng5x+1S54oOBj3yAKW r+SKUkd/QZeNc/1YLwqXGDOmqVB097PIbGDIIrEmgqtq1J7k5OyILndie/t3/DVu 0fXWLoJt7gmYnOQ76GmPTR361vw8mm8PXnkCCkUzkAMfiK0Fh1KtpZaxLfjET4bf ZVvdLYQHJ/SQ5ta+I2/RsbjedGtE12Mw5iBjAvykllXxdFueXCuJgMcLdfvQmF1U YOMmUGSdyD7jjs+w1+5Y9CaQNV8QDNDwtwrLHxgHQw7EykwyukhiH1Rm2rdpaaHK SUJiiotI+M/Qw1S+RKlrdSlMi3MKcWZUhaF0BMDDRQHf9LA06CTQsSZ248WrbFH3 qaebV8TetxBss58iGYT/1d6MXcB477UxWaFarNqCT+gd4J2KZA6aKS9SEVFhZXwe 3vdjRQXRgx7ToN4eENuA =ZGGN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeremy, On 7/2/13 6:26 PM, Majors, Jeremy wrote: Sorry for the miscommunication. I understand that active users with a session are supposed to stay with the original version that they were associated with. My confusion was caused by the fact that when I did an auto deploy, the users were immediately being migrated to the new version of the application. I would not have expected this because I thought that the cookies attribute is set to true by default and thus they would have an active session. However, I have been able to achieve my desired results by setting cookies=false within the context files for the applications I manually deployed. This indicates to me that you don't have JMeter properly configured with a cookie-based session manager. If you have that, your users should remain logged-in (and looking at the old version of the webapp). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR24lbAAoJEBzwKT+lPKRYFsIQAKiHTuAYJFiRWsFdln6QciTt FE/xDACFesQpNZB7BCXVhn0wJrGcd3JMgljEo3FYqBxhDYyMlkfCFzr400Eo6HOn 6zEpnLMgDZSpYGcNxEmNHZeiNoI5gNT+qLuQ97avxul1YRP4r5/vPW3qdhwiV9x9 wDa3bhAf9XNJpeDOPeXo9xT+rVNzwyy2okF8685j/4s6CsA0IbTWN1L+DyyCY47s y2Yq6e+f8/iHbCk3ZfcoHmhFsy7JMp54ZOIlzAYmGrLPuUdMh841TMHSMOk+ed9F anN4hBv9iwu1MylepMwXUqIj66589md5iEa0i7mAHsGiAk28rX+W/JEXtEkjYVRf 893m1G1Wn2BVlWjqliXvh8/BkG2+IPP6a/dBLi65gsvWjIMmgUcJYYmuMsv0szju sKBDtCdhoLsaRXqlgTbOVI1SZb5p0MDXkRp0+mUp4LQyi2d3zDM7wLSsi4q+7i6v RfLko0MBRctB/PqqjdPKtKLOP3s7J1bgvD76hLE1zcQJJxSJuQMi9AwOzTrsRAVx v1KV9RjlQKEtNQYMkUIxTqWbGN4kj7D4/RJ4UeVS8g+XKsCBe6sHUitw7pEkchTl ywCfKEB5aBQth5jzlXzz678zA8NSXBJ2MrnINM8lizq0+iCtkjiXaTVhdNCiE5V0 hNc2aKkKDPRSfl8myteG =oPu0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
I'm testing out the parallel deployment process for my company and am seeing a difference in how user migrations to the new version of the application occur based upon how you deploy your application. Our configuration involves many different web sites that all point to the same folder. Some example context configuration files are provided below to help illustrate what I mean: Website1.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Website2.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Website3.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Yesterday some individuals from this mailing list helped me understand that if I create a new context file with ##001 appended at the end then that will allow me to deploy a new version of the application. For example: Website1##002.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp-v2/Context When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Can anyone explain why I'm seeing a difference in the behavior between the two deployment mechanisms and if so, how would I mimic what is happening in regards to the automatic migration of users to new versions while using the folder deployment approach. Thank you very much for your assistance, Jeremy
Re: Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeremy, On 7/2/13 12:09 PM, Majors, Jeremy wrote: When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. Are you sure that JMeter is creating new users during its test? Usually JMeter is configured to execute a workflow and preserve cookies, just as a real user with a browser would. So, if you have 100 users running your test(s) indefinitely, you'll only get 100 sessions no matter what. If they all are created before you deploy your new webapp version, then those sessions will remain attached to the old version (that's how parallel deployment works). What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. I think you need to look carefully at what is really happening. It's not clear from above how you are triggering a parallel deployment in each case. It basically sound like you are saying while it does not work, it actually does. Please be clear about what you are doing when you think it works and what you are doing when you think it doesn't work. Also tell us what you expect and why, and what happens instead. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Do your JMeter users ever log out? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR0yWbAAoJEBzwKT+lPKRY4y8QAJ9d9Rfth362CgMpvKaT/zQH LMvUBr4jJT5YjkwKhK3qXXzOHuJRvBtFZy4ul/4TERR8p8fUChnVTTTVWPPdfw2f TbXiVjGpgVyveRMWRQSGHukHSelUvN9SkkEfxkD5x6oZj4lWTNsZ4mTUgmOYAwsG z6xchc6CJF1Cay9mE/vgzhYQrbYH/A2XuH7BlSWqH6JzMz1r+BrOpiIETwCnr0bv sdUQPwFIT3EEjz+rKBwcseVQ2arsEsJ+iI9RCVVy31AF0Eno1oWxm6OLSEHTDs68 MLUj9rNULv8ZogJ9XPLlqowwCr8ve3e8DmhLzG4Ye4j+OnJlx/87CQnv8XFNqH9I IpWw4mQYGoYXw4mDhQT7P3NRhLzuaA14RVI2vkj2DPY7qj9Oj47YRfAF5gjZjNTK lq5etTiG4TiwzvzadvsXpz/zzIUG/RQ489DeDLlkT/7PwKaohwG5xIHPC+JK/+Xd FjbkW92fYy6g2w+GA3L3mUZmeWI1XX0EyS6vIX9MPmOmkNGrKLLfc9uS3ArDMAh2 h9rTt3t+ahun0RcTDEtxQYeMDXWVgZ+eyTzvxGpkHE/Q64n/U+lcuh9P+lOsuH0c +1fCbCveQOB9h5L0Oqbc5Ha+e19VmdtkkpMP4VwV0YljoSsO7Zrmpj9F79CE+wSW twskY9X1dH+qzoPyP0+v =MPUQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
Sorry for the miscommunication. I understand that active users with a session are supposed to stay with the original version that they were associated with. My confusion was caused by the fact that when I did an auto deploy, the users were immediately being migrated to the new version of the application. I would not have expected this because I thought that the cookies attribute is set to true by default and thus they would have an active session. However, I have been able to achieve my desired results by setting cookies=false within the context files for the applications I manually deployed. Thanks, Jeremy On 7/2/13 2:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeremy, On 7/2/13 12:09 PM, Majors, Jeremy wrote: When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. Are you sure that JMeter is creating new users during its test? Usually JMeter is configured to execute a workflow and preserve cookies, just as a real user with a browser would. So, if you have 100 users running your test(s) indefinitely, you'll only get 100 sessions no matter what. If they all are created before you deploy your new webapp version, then those sessions will remain attached to the old version (that's how parallel deployment works). What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. I think you need to look carefully at what is really happening. It's not clear from above how you are triggering a parallel deployment in each case. It basically sound like you are saying while it does not work, it actually does. Please be clear about what you are doing when you think it works and what you are doing when you think it doesn't work. Also tell us what you expect and why, and what happens instead. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Do your JMeter users ever log out? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR0yWbAAoJEBzwKT+lPKRY4y8QAJ9d9Rfth362CgMpvKaT/zQH LMvUBr4jJT5YjkwKhK3qXXzOHuJRvBtFZy4ul/4TERR8p8fUChnVTTTVWPPdfw2f TbXiVjGpgVyveRMWRQSGHukHSelUvN9SkkEfxkD5x6oZj4lWTNsZ4mTUgmOYAwsG z6xchc6CJF1Cay9mE/vgzhYQrbYH/A2XuH7BlSWqH6JzMz1r+BrOpiIETwCnr0bv sdUQPwFIT3EEjz+rKBwcseVQ2arsEsJ+iI9RCVVy31AF0Eno1oWxm6OLSEHTDs68 MLUj9rNULv8ZogJ9XPLlqowwCr8ve3e8DmhLzG4Ye4j+OnJlx/87CQnv8XFNqH9I IpWw4mQYGoYXw4mDhQT7P3NRhLzuaA14RVI2vkj2DPY7qj9Oj47YRfAF5gjZjNTK lq5etTiG4TiwzvzadvsXpz/zzIUG/RQ489DeDLlkT/7PwKaohwG5xIHPC+JK/+Xd FjbkW92fYy6g2w+GA3L3mUZmeWI1XX0EyS6vIX9MPmOmkNGrKLLfc9uS3ArDMAh2 h9rTt3t+ahun0RcTDEtxQYeMDXWVgZ+eyTzvxGpkHE/Q64n/U+lcuh9P+lOsuH0c +1fCbCveQOB9h5L0Oqbc5Ha+e19VmdtkkpMP4VwV0YljoSsO7Zrmpj9F79CE+wSW twskY9X1dH+qzoPyP0+v =MPUQ -END PGP SIGNATURE- - 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 Upgrade Migration Questions
On Feb 6, 2013, at 1:24 AM, Kirk Hoganson wrote: I am currently in the middle of an upgrade from Apache (2.2)/Tomcat (5.5.16) to Apache (2.2)/Tomcat (6.0.24). The JVM is being upgraded from 1.5.0_09-b01 to 1.6.0_22-b22. The new host servers will be RedHat 6.2. Why are you upgrading to 6.0.24 Java 1.6.0_22? These are already multiple versions out of date. Do yourself a favor and upgrade to the latest release of each, which at this time is 6.0.36 and Java 1.6.0_39. I would like to use the default application installation paths used by the RPMs. I can understand the temptation to do this, but you should really install Tomcat direct from http://tomcat.apache.org. You'll get the latest version and it's packaged in a way that is familiar to everyone on this list, which means we can help you with problems. However, I would like the user code base(s) to exist in a separate partition. These servers will be hosting multiple separate java applications. Not sure what you mean by code base. Are you referring to the WAR files for your applications? If so, those are normally placed into your webapps directory. You can change that directory by changing the appBase attribute of the Host/ tag. https://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Common%20Attributes Or you can place a context file in conf/service/host/appName.xml and use docBase to specify the location of your WAR file. Note, you would only do this if the path to the WAR file is not inside your webapps (i.e. appBase) directory already. https://tomcat.apache.org/tomcat-6.0-doc/config/context.html Currently Apache and Tomcat use mod_jk as the connector. I am hoping for some advice that will help me with the server/Tomcat/Apache configuration. I am specifically interested in Tomcat configuration advice, or direction. I would like to get some clarification on the following questions: How can I configure Tomcat to allow each individual application (JVM) to be restarted independently? - We currently do this with separate CATALINA_BASE directories, and separate startup/shutdown scripts. I’m not sure if that is the cleanest way. If you need to isolate your applications, i.e. one application per JVM, then this is the way to go. It will also allow you to restart your Tomcat servers independently. It may seem like a waste of memory, but the overhead of Tomcat is very small so it's not as bad as you might initially think. An alternative approach would be to run all of your web apps in one Tomcat instance. You could then reload individual applications using the Manager interface or you could undeploy / redeploy them. This will restart your applications, but it's not quite the same as restarting the Tomcat server. What you do depends on your needs. What method would best allow Apache to serve static content, and Tomcat to server java based dynamic content? - I’m assuming this will depend on the connector used. The exact configuration to use will depend on how you proxy to your Tomcat server. That being said, the general idea is that you keep requests to your static resources from being proxied to your Tomcat servers. This then allows Apache HTTPD to service those requests. This can either be done inclusively, i.e. by mapping only the paths which should be proxied, or exclusively by proxying everything and specify certain paths that should not be proxied. With mod_proxy, you use ProxyPass and ProxyPass with an ! (excludes) at the end of the path. Ex: ProxyPass /myapp ProxyPass /myapp/static ! With mod_jk, you use JkMount and JkUnMount. Which connector (mod_jk, mod_proxy_ajp, mod_cluster) should be used? http://markmail.org/message/dftgdokeyebqd4ep?q=deciding-between-modjk-modproxyhttp-and-modproxyajp - I have heard conflicting reports about mod_jk being deprecated or not. This is not true. There are similarly named projects that you shouldn't use though, like mod_jk2, mod_jserv and mod_webapp. - I have seen benchmarks with mod_proxy_ajp outperforming mod_jk significantly. I have not heard this, where did you see these? Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Upgrade Migration Questions
On Feb 6, 2013, at 1:24 AM, Kirk Hoganson wrote: I am currently in the middle of an upgrade from Apache (2.2)/Tomcat (5.5.16) to Apache (2.2)/Tomcat (6.0.24). The JVM is being upgraded from 1.5.0_09-b01 to 1.6.0_22-b22. The new host servers will be RedHat 6.2. Why are you upgrading to 6.0.24 Java 1.6.0_22? These are already multiple versions out of date. Do yourself a favor and upgrade to the latest release of each, which at this time is 6.0.36 and Java 1.6.0_39. Just want to chime in here. Please note that Java 6 is 8 years old, as of February 2011 Oracle ended public update notifications, and (most importantly) as of February 2013 (this month) Java 6 will be END OF LIFE (http://www.oracle.com/technetwork/java/eol-135779.html). This means that if some security issue is identified in Java 6 that could compromise your servers, the only way you will be able to get a fix for it is to upgrade to Java 7. (Java 7 is approaching its second birthday and Java 8 comes out later this year. The plan is for Java 7 to go end of life in July 2014, but July 2012 was the plan for Java 6 and that got extended 7 months. I think Java 7 has a little time left in it yet.) Dan is right to encourage you to go to Java 1.6.0_39 instead of 1.6.0_22 and to go to Tomcat 6.0.36 instead of 6.0.24. The versions you are proposing to update to are out of date, potentially insecure, and should not be used on production systems. However, I would take it a step further. If you are already in the process of upgrading your systems, get a little more current and save yourself some headache down the road. Get Java 1.7.0_13 and Tomcat 7.0.35. That should last you for a couple more years before you'll need to update. Just my $0.02. Nick This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Upgrade Migration Questions
I am currently in the middle of an upgrade from Apache (2.2)/Tomcat (5.5.16) to Apache (2.2)/Tomcat (6.0.24). The JVM is being upgraded from 1.5.0_09-b01 to 1.6.0_22-b22. The new host servers will be RedHat 6.2. I would like to use the default application installation paths used by the RPMs. However, I would like the user code base(s) to exist in a separate partition. These servers will be hosting multiple separate java applications. Currently Apache and Tomcat use mod_jk as the connector. I am hoping for some advice that will help me with the server/Tomcat/Apache configuration. I am specifically interested in Tomcat configuration advice, or direction. I would like to get some clarification on the following questions: How can I configure Tomcat to allow each individual application (JVM) to be restarted independently? - We currently do this with separate CATALINA_BASE directories, and separate startup/shutdown scripts. I’m not sure if that is the cleanest way. What method would best allow Apache to serve static content, and Tomcat to server java based dynamic content? - I’m assuming this will depend on the connector used. Which connector (mod_jk, mod_proxy_ajp, mod_cluster) should be used? - I have heard conflicting reports about mod_jk being deprecated or not. - I have seen benchmarks with mod_proxy_ajp outperforming mod_jk significantly. - I don’t think we currently need the clustering functionality of mod_cluster, but may with future JBoss installations. Thanks in advance for your suggestions.
Migration Tomcat 5x to 7.0.8
Team, We are migrating form tomcat 5x to 7.0.8 In Tomcat 5.0 we are defining the url below url = path/APReports/servlet/com.nielsenmedia.umi.ap.hwsw.QuerySWServlet; and sending the request using the ajax Like o.open(POST, url , true); So I am not getting any problem in Tomcat 5 In Tomcat7, I am getting below error PBrush What are the changes required to do in Tomcat 7.0.8. Thanks KiranKumar P ole0.bmp
Re: Migration Tomcat 5x to 7.0.8
2011/8/19 Kumar, Kiran P kiran.p.kumar...@nielsen.com Team, We are migrating form tomcat 5x to 7.0.8 In Tomcat 5.0 we are defining the url below url = path/APReports/servlet/com.nielsenmedia.umi.ap.hwsw.QuerySWServlet; and sending the request using the ajax Like o.open(POST, url , true); So I am not getting any problem in Tomcat 5 In Tomcat7, I am getting below error What are the changes required to do in Tomcat 7.0.8. Do not use invoker servlet. It is broken by design. You have to provide mappings for all your servlets explicitly, e.g.: servlet servlet-nameQuerySWServlet/servlet-name servlet-classcom.nielsenmedia.umi.ap.hwsw.QuerySWServlet/servlet-class /servlet servlet-mapping servlet-nameQuerySWServlet/servlet-name url-pattern/servlet/com.nielsenmedia.umi.ap.hwsw.QuerySWServlet/url-pattern /servlet-mapping (servlet name can be arbitrary but must be the same between servlet and servlet-mapping). See here for longer story, and it is also mentioned in the FAQ: http://www.coderanch.com/how-to/java/InvokerServlet Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Custom Realm - Tomcat 5.5 to Tomcat 7 Migration
I have a custom realm that is quite complex and uses a variety of third party libraries, including Spring. In Tomcat 5.5, I placed the Realm and all of the JARs it depended upon in the server/lib directory. This kept these classes in the Catalina class loader, which was not visible to any web applications. This was the perfect solution since I do not want to automatically include all of these JARs in the classloading hierarchy of my web applications. Now I am trying to migrate to Tomcat 7, and having a hard time figuring out a way to create the same configuration. I see that there is no longer a Catalina classloader or any classloader that won't be visible to the web applications. Is that accurate or is there some way to isolate certain JAR files and prevent them from being visible to my web applications? Also, I'm thinking that another option could be to have a separate web application for authentication. Would I be able to do this and still integrate with the Realm concept in Tomcat? As a side note, I'm working in a portal environment so I use the SSO valve and basically want a single point of authentication for all web applications (i.e. portlets) deployed in the servlet container. Thanks, Steve
Re: Custom Realm - Tomcat 5.5 to Tomcat 7 Migration
2011/8/19 Steve Ratay steve.ra...@yahoo.com: I have a custom realm that is quite complex and uses a variety of third party libraries, including Spring. In Tomcat 5.5, I placed the Realm and all of the JARs it depended upon in the server/lib directory. This kept these classes in the Catalina class loader, which was not visible to any web applications. This was the perfect solution since I do not want to automatically include all of these JARs in the classloading hierarchy of my web applications. Now I am trying to migrate to Tomcat 7, and having a hard time figuring out a way to create the same configuration. I see that there is no longer a Catalina classloader or any classloader that won't be visible to the web applications. It is possible to reenable classloader hierarchy of Tomcat 5.5 by editing Tomcat 7's catalina.properties file, but I heard that there is a catch that usually you cannot just place your files into server classloader - there is some dependency between components and some jars have to be moved into this classloader as well. YMMV. Is that accurate or is there some way to isolate certain JAR files and prevent them from being visible to my web applications? Just random thought - maybe you can create your own instance of UrlClassLoader (it is easy) and load your classes through it? Though I do not know why the same wouldn't go with the server classloader discussed above. Also, I'm thinking that another option could be to have a separate web application for authentication. Would I be able to do this and still integrate with the Realm concept in Tomcat? Web applications are not guaranteed to start in any certain order. A Web application can be restarted at any time (and its classloader is stopped and disposed when a web application stops). Web applications are isolated and do not see each other's ckassloaders. Those are main problems if you want to deploy a shared component as a web application. As a side note, I'm working in a portal environment so I use the SSO valve and basically want a single point of authentication for all web applications (i.e. portlets) deployed in the servlet container. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slow SSL connections after Tomcat 5 to 7 migration
W dniu 2011-05-05 18:50, Christopher Schultz pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michał, On 5/5/2011 10:21 AM, Michał Kapituła wrote: I thought that seperate SSL Handshake could be made for each of the requests, but I can't see such behaviour in the dumps. Only one or zero threads commiting a handshake, others appear to autoaccept it (maybe not a precise term). [snip] No, nothing changed. Btw - the Tomcat version is 7.0.12 and JDK's is 6.0.14 If you are using the BIO connector (which it looks like you are due to org.apache.coyote.http11.Http11Protocol in yourConnector), then Tomcat doesn't have a great deal of control over the SSL handshake, etc. process. That's all up to the JRE itself since all of the SSL implementation comes from there. Tomcat can affect certain things like the ciphers used, etc. but basically everything is done by the runtime, not by Tomcat. Can you double-check to see if you are using the APR versions of the HTTP connectors? The best way to tell what's going on is to look at the startup messages when the connectors initialize themselves and emit a short log message to catalina.out. That will tell us what connector is actually being used. Yes, I'm positive that I'm using Java BIO connector, not the APR one (as I said before, I can't use one). I've managed to run exact copy of production system's Tomcat on my own machine, so I'll have an opportunity to run these apps in Eclipse, experiment more with NIO connector and different server configurations, look in the jdk and tomcat source and maybe I'll find what's taking so long. Still I'm open for any new ideas from anyone. Regards, Michał - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slow SSL connections after Tomcat 5 to 7 migration
Hello, I've made some thread dumps with https connection in progress. W dniu 2011-05-04 15:49, Caldarale, Charles R pisze: From: Michał Kapituła [mailto:michal.kapit...@comarch.pl] Subject: Slow SSL connections after Tomcat 5 to 7 migration I've just tested the page generation time via local network (and browser's cache off) and the page is being fully loaded in circa 2 seconds (with Firebug on) when using http, while loading the same page using secure connection took as much as 10 times longer. If the CPU usage is not high during page generation over SSL, and the network isn't inducing delays, then the threads must be waiting for something. Can you take some thread dumps during the delay period and find out what they're stuck on? (My suspicion is reads from /dev/random, but I thought that was only during Tomcat initialization.) Really I don't know what to search for there (maybe you could give me some clues?). Could you explain why reading from /dev/random possibly could be the case here? I thought that seperate SSL Handshake could be made for each of the requests, but I can't see such behaviour in the dumps. Only one or zero threads commiting a handshake, others appear to autoaccept it (maybe not a precise term). Also, is Tomcat front-ended by anything (e.g., httpd), or are you accessing it directly? No, it isn't. Did anything else change when you upgraded Tomcat? For example, the JVM version? No, nothing changed. Btw - the Tomcat version is 7.0.12 and JDK's is 6.0.14 I'll update JDK tommorow, I'm not sure if it will change anything, but won't hurt neither... I'll appretiate any additional help from you guys. Maybe there's any additional info I could provide to make things more clear? Please let me know. Regards, Michał - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slow SSL connections after Tomcat 5 to 7 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michał, On 5/5/2011 10:21 AM, Michał Kapituła wrote: I thought that seperate SSL Handshake could be made for each of the requests, but I can't see such behaviour in the dumps. Only one or zero threads commiting a handshake, others appear to autoaccept it (maybe not a precise term). [snip] No, nothing changed. Btw - the Tomcat version is 7.0.12 and JDK's is 6.0.14 If you are using the BIO connector (which it looks like you are due to org.apache.coyote.http11.Http11Protocol in your Connector), then Tomcat doesn't have a great deal of control over the SSL handshake, etc. process. That's all up to the JRE itself since all of the SSL implementation comes from there. Tomcat can affect certain things like the ciphers used, etc. but basically everything is done by the runtime, not by Tomcat. Can you double-check to see if you are using the APR versions of the HTTP connectors? The best way to tell what's going on is to look at the startup messages when the connectors initialize themselves and emit a short log message to catalina.out. That will tell us what connector is actually being used. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3C1WgACgkQ9CaO5/Lv0PAUqQCfQ7hQtIx6VTlUTIm34BagDGMh 9gAAmwWcAqVhBhqt0CngBQT9fmwCX30I =0pxy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Slow SSL connections after Tomcat 5 to 7 migration
From: Michał Kapituła [mailto:michal.kapit...@comarch.pl] Subject: Re: Slow SSL connections after Tomcat 5 to 7 migration Really I don't know what to search for there (maybe you could give me some clues?). Look to see what the threads are doing. Some will be waiting on monitors, some might actually be doing work, some might be stuck on I/O requests. You have to look at each call stack to see (a laborious process, unfortunately). It's often useful to take several thread dumps a few seconds apart and see what's changing and what isn't. Could you explain why reading from /dev/random possibly could be the case here? Because /dev/random (unlike /dev/urandom) can wait an arbitrarily long time to gather enough randomness before returning data. This is especially problematic on virtual machines running as servers, which have very little going on to generate entropy. - 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.
Slow SSL connections after Tomcat 5 to 7 migration
Hi, I've been experiencing trouble after migrating our company's web application from Tomcat 5 to Tomcat 7. There's a significant slowdown with https connections after the migration. I'm aware that application has a flaw - there's a large number of http request needed for generating a page ( 100 requests), but these are mainly static content (css, js, images etc.) and only very limited (1-3) ammount of requests are for dynamically generated content. I've just tested the page generation time via local network (and browser's cache off) and the page is being fully loaded in circa 2 seconds (with Firebug on) when using http, while loading the same page using secure connection took as much as 10 times longer. It's extremely weird for me, since I haven't noticed any significant differences between Tomcat 5 and 7 approaches to SSL and the server.xml file is pretty much the same. Problems associated with server load, heavy user traffic or JVM params are rather not an option here. The memory and CPU usage constantly stays lower than with Tomcat 5. Here are crucial parts of our server.xml file: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=400 minSpareThreads=300 prestartminSpareThreads=true / Connector port=80 protocol=HTTP/1.1 executor=tomcatThreadPool enableLookups=false redirectPort=443 acceptCount=200 tcpNoDelay=true connectionTimeout=2 maxKeepAliveRequests=200 disableUploadTimeout=true URIEncoding=UTF-8 compression=on compressableMimeType=application/javascript,text/html,text/xml,text/javascript,text/css,text/plain,application/json,text/json,application/xml / Connector port=443 protocol=org.apache.coyote.http11.Http11Protocol executor=tomcatThreadPool address=192.168.100.100 enableLookups=false disableUploadTimeout=true keystorePass=XXX keystoreFile=XXX acceptCount=200 scheme=https secure=true SSLEnabled=true clientAuth=true sslProtocol=TLS truststoreFile=XXX truststorePass=XXX URIEncoding=UTF-8 compression=on compressableMimeType=application/javascript,text/html,text/xml,text/javascript,text/css,text/plain,application/json,text/json,application/xml / Connector port=443 protocol=org.apache.coyote.http11.Http11Protocol executor=tomcatThreadPool enableLookups=false disableUploadTimeout=true acceptCount=200 scheme=https secure=true SSLEnabled=true address=192.168.100.101 clientAuth=true sslProtocol=TLS keystorePass=XXX keystoreFile=XXX truststoreFile=XXX truststorePass=XXX URIEncoding=UTF-8 compression=on compressableMimeType=application/javascript,text/html,text/xml,text/javascript,text/css,text/plain,application/json,text/json,application/xml / Well, except for defining global thread pool nothing really changed between our versions' configuration. I've experimented with Java Nio Blocking Connector, but haven't noticed any significant improvement. Also can't use APR Connector, because it's some kind of requirement that we must use keystore files we already have. Any ideas on how to improve SSL performance and what could possibly go wrong? Sorry for my English, for I'm not a native speaker :). Regards, MK - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Slow SSL connections after Tomcat 5 to 7 migration
From: Michał Kapituła [mailto:michal.kapit...@comarch.pl] Subject: Slow SSL connections after Tomcat 5 to 7 migration I've just tested the page generation time via local network (and browser's cache off) and the page is being fully loaded in circa 2 seconds (with Firebug on) when using http, while loading the same page using secure connection took as much as 10 times longer. If the CPU usage is not high during page generation over SSL, and the network isn't inducing delays, then the threads must be waiting for something. Can you take some thread dumps during the delay period and find out what they're stuck on? (My suspicion is reads from /dev/random, but I thought that was only during Tomcat initialization.) Also, is Tomcat front-ended by anything (e.g., httpd), or are you accessing it directly? Did anything else change when you upgraded Tomcat? For example, the JVM version? Sorry for my English, for I'm not a native speaker :). It's better than that of many who are... - 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.
Re: Slow SSL connections after Tomcat 5 to 7 migration
On Wed, May 4, 2011 at 15:49, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Michał Kapituła [mailto:michal.kapit...@comarch.pl] Subject: Slow SSL connections after Tomcat 5 to 7 migration I've just tested the page generation time via local network (and browser's cache off) and the page is being fully loaded in circa 2 seconds (with Firebug on) when using http, while loading the same page using secure connection took as much as 10 times longer. If the CPU usage is not high during page generation over SSL, and the network isn't inducing delays, then the threads must be waiting for something. Can you take some thread dumps during the delay period and find out what they're stuck on? (My suspicion is reads from /dev/random, but I thought that was only during Tomcat initialization.) Also, is Tomcat front-ended by anything (e.g., httpd), or are you accessing it directly? Did anything else change when you upgraded Tomcat? For example, the JVM version? Can it be the same problem that I encountered with the long deployment time of the manager webapp, which is cured by changing the entropy source file? -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
migration from apache tomcat 5.5.20 to 6.0.26 procedure required.
Hi All, I have to migrate the existing tomcat from 5.5.20 to 6.0.26. As i found that the folders common and shared do not exist in 6.0.26. So I am not sure how to migrate from the current to the latest. Please send me the procedure for successful migration without any loss of files and folders. Regards Prakash
Re: migration from apache tomcat 5.5.20 to 6.0.26 procedure required.
On 03/06/2010 12:21, prakash mahavrataya wrote: Hi All, I have to migrate the existing tomcat from 5.5.20 to 6.0.26. As i found that the folders common and shared do not exist in 6.0.26. So I am not sure how to migrate from the current to the latest. Please send me the procedure for successful migration without any loss of files and folders. Step 1: read the documentation for version 6.0. http://tomcat.apache.org/tomcat-6.0-doc/ Carefully read the release notes, changelog etc. Step 2: download and install the current binary and familiarise yourself with the config files and new layout. If you have specific questions, come back and ask them. p Regards Prakash signature.asc Description: OpenPGP digital signature
Re: migration from apache tomcat 5.5.20 to 6.0.26 procedure required.
On 03/06/2010 12:28, Pid wrote: On 03/06/2010 12:21, prakash mahavrataya wrote: Hi All, I have to migrate the existing tomcat from 5.5.20 to 6.0.26. As i found that the folders common and shared do not exist in 6.0.26. So I am not sure how to migrate from the current to the latest. Please send me the procedure for successful migration without any loss of files and folders. Step 1: read the documentation for version 6.0. http://tomcat.apache.org/tomcat-6.0-doc/ Carefully read the release notes, changelog etc. Also http://tomcat.apache.org/migration.html Mark Step 2: download and install the current binary and familiarise yourself with the config files and new layout. If you have specific questions, come back and ask them. p Regards Prakash - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5.28 to 6.0.20 migration question
Hi all, I’m using a program called EMC Smarts which is a network monitoring tool. It can accommodate a web interface using Tomcat, which is currently version 5.5.28 and works perfectly. I am trying to upgrade to version 6.0.20 but am having some trouble. Smarts official documentation for Tomcat upgrades says to rename the tomcat folder within the Smarts directory to tomcat-old and just unzip the new one in place of the old one (and rename it to what the old one was named). But also needed are several folders from the old install, specifically tss, templates and webconsole, as well as the SMViewletAuth.war file from the webapps folder. They are supposed to be pasted into the new install. I’ve done all this (I did the same process which worked to get to 5.5.28), and Tomcat no longer works. I read on the migration page that there are some directory structure differences between Tomcat 5 and 6, but I am no Tomcat expert, in fact today is the first time I’ve had to deal with it at all. I know my version of java is good, and I looked in conf/catalina.properties and noticed that there are differences, but I have no idea if this matters. I have requested support from EMC about this, but I do not have high hopes. Any input at all would be appreciated. --Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5.28 to 6.0.20 migration question
From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Tomcat 5.5.28 to 6.0.20 migration question Tomcat no longer works. Care to tell us what that means? Log entries, error messages, anything useful? Or do we have to call Pid to get him to use his Internet Telepathy? - 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
Re: Tomcat 5.5.28 to 6.0.20 migration question
Chuck, I can't get to the server at the moment but I'm an absolute noob. The way I know it doesn't work is that when I go to http://tomcat server:8080 I don't get the tomcat screen that comes up with version 5.5.28. Just page cannot be displayed. As soon as I am allowed, I'll check the log files (which I hope are in /logs folder). Tomcat is run as a service by the Smarts program when it starts, and the service does start, so I'm not sure where I would see errors. Also, a little telepathy couldn't hurt. --Mike On Thursday, November 5, 2009, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Tomcat 5.5.28 to 6.0.20 migration question Tomcat no longer works. Care to tell us what that means? Log entries, error messages, anything useful? Or do we have to call Pid to get him to use his Internet Telepathy? - 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 5.5.28 to 6.0.20 migration question
Caldarale, Charles R wrote: From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Tomcat 5.5.28 to 6.0.20 migration question Tomcat no longer works. Care to tell us what that means? Log entries, error messages, anything useful? Or do we have to call Pid to get him to use his Internet Telepathy? Michael, since you are new here, don't go misinterpreting the above. Chuck is a bit rough sometimes, but he's good. And the above contains a hint that he might even be inclined to help, if you provide some more info. Cos' if he wasn't, he'd just have told you to go find yourself a Smarts forum. ;-) And by the way, Pid is another one of the gurus here. His specialty is to devine, at long distance and with minimal information, what actually does not work. But we keep him in reserve for the really bizarre cases, ghostbusters-like. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5.28 to 6.0.20 migration question
From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Re: Tomcat 5.5.28 to 6.0.20 migration question when I go to http://tomcatserver:8080 I don't get the tomcat screen that comes up with version 5.5.28. Just page cannot be displayed. Sounds like you're using IE as your browser; if so, I'd strongly recommend picking anything else, since IE likes to hide errors behind its friendly error pages (which can be turned off). As soon as I am allowed, I'll check the log files (which I hope are in /logs folder). When using a 3rd-party repackaged or an embedded version of Tomcat, there's no telling where the logs are; you may have to hunt for them. Also, since the log file names are configurable, the repackaged/embedded version might not even be using the normal file names, let alone locations. You might try experimenting a bit with a standard Tomcat download from tomcat.apache.org to get an idea of what to expect. Also, a little telepathy couldn't hurt. It's 21:50 where Pid is, so that might have to wait until tomorrow. - 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
Re: Tomcat 5.5.28 to 6.0.20 migration question
Michael C wrote: Chuck, I can't get to the server at the moment but I'm an absolute noob. The way I know it doesn't work is that when I go to http://tomcat server:8080 I don't get the tomcat screen that comes up with version 5.5.28. Just page cannot be displayed. As soon as I am allowed, I'll check the log files (which I hope are in /logs folder). Tomcat is run as a service by the Smarts program when it starts, and the service does start, so I'm not sure where I would see errors. Also, a little telepathy couldn't hurt. Mmm. Maybe I can gain some credits on my long-distance devination rating here. Let me feel the nodes and receive the vibes.. what do I see ? I see.. a system.. a Windows system.. with a Smarts directory, and in it a tomcat directory... and that tomcat directory looks like it contains a logs directory, where there might well be some file which would tell Chuck what happens. it also seems to contain a bin directory, with a program called tomcat6w.exe. and when you double-click on that one, it opens a dialog. and in that dialog, there are plenty of things, like a path to a JVM and stuff. also, in Windows there are Event logs. Sometimes they also contain interesting stuff about Services. there is also, under the tomcat directory, a /conf directory, with a file in it called server.xml. I would bet that it contains at least one part looking like Connector port=8080 ... and if it does not, it probably should. I mean, instead of 8180 or something. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5.28 to 6.0.20 migration question
Chuck, I fully agree about IE but the people in charge don't wanna hear it. The fact that this is a third party tomcat install confuses me even more than if it was normal, and definitely frustrating that the logs could be anywhere. If we pretend I did have a normal install, are there any extra steps involved going from 5 to 6 that could be useful? Because going from 5.5.17 to 5.5.28 was extremely easy, following the steps I said in the original email. I do plan on experimenting with a vanilla install tomorrow (I get access tomorrow afternoon since everyone will be gone) but not sure how helpful it will be given the third party nature. --Mike On Thursday, November 5, 2009, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Re: Tomcat 5.5.28 to 6.0.20 migration question when I go to http://tomcatserver:8080 I don't get the tomcat screen that comes up with version 5.5.28. Just page cannot be displayed. Sounds like you're using IE as your browser; if so, I'd strongly recommend picking anything else, since IE likes to hide errors behind its friendly error pages (which can be turned off). As soon as I am allowed, I'll check the log files (which I hope are in /logs folder). When using a 3rd-party repackaged or an embedded version of Tomcat, there's no telling where the logs are; you may have to hunt for them. Also, since the log file names are configurable, the repackaged/embedded version might not even be using the normal file names, let alone locations. You might try experimenting a bit with a standard Tomcat download from tomcat.apache.org to get an idea of what to expect. Also, a little telepathy couldn't hurt. It's 21:50 where Pid is, so that might have to wait until tomorrow. - 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 5.5.28 to 6.0.20 migration question
From: Michael C [mailto:tomcat6d...@gmail.com] Subject: Re: Tomcat 5.5.28 to 6.0.20 migration question I fully agree about IE but the people in charge don't wanna hear it. I didn't mean for everyone, just for your testing until things are sorted. If we pretend I did have a normal install, are there any extra steps involved going from 5 to 6 that could be useful? Not really; the config is pretty much the same, other than for clustering. There are a few new options for 6.0, but nothing that should stop your webapps from working. There are some Jasper fixes for spec compliance that may result in incompatibilities, and these can be disabled by setting the appropriate system properties. Whether or not they're of consequence can't be determined without looking at the logs. http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.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
Re: Tomcat 5.5.28 to 6.0.20 migration question
Andre, From what I'm able to remember, that's amazing! Also I will check all of those places as soon as I'm allowed back on. I'm almost certain server.XML contains 8080. -Mike On Thursday, November 5, 2009, André Warnier a...@ice-sa.com wrote: Michael C wrote: Chuck, I can't get to the server at the moment but I'm an absolute noob. The way I know it doesn't work is that when I go to http://tomcat server:8080 I don't get the tomcat screen that comes up with version 5.5.28. Just page cannot be displayed. As soon as I am allowed, I'll check the log files (which I hope are in /logs folder). Tomcat is run as a service by the Smarts program when it starts, and the service does start, so I'm not sure where I would see errors. Also, a little telepathy couldn't hurt. Mmm. Maybe I can gain some credits on my long-distance devination rating here. Let me feel the nodes and receive the vibes.. what do I see ? I see.. a system.. a Windows system.. with a Smarts directory, and in it a tomcat directory... and that tomcat directory looks like it contains a logs directory, where there might well be some file which would tell Chuck what happens. it also seems to contain a bin directory, with a program called tomcat6w.exe. and when you double-click on that one, it opens a dialog. and in that dialog, there are plenty of things, like a path to a JVM and stuff. also, in Windows there are Event logs. Sometimes they also contain interesting stuff about Services. there is also, under the tomcat directory, a /conf directory, with a file in it called server.xml. I would bet that it contains at least one part looking like Connector port=8080 ... and if it does not, it probably should. I mean, instead of 8180 or 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: Tomcat 5.5.28 to 6.0.20 migration question
Michael C wrote: Chuck, I fully agree about IE but the people in charge don't wanna hear it. The fact that this is a third party tomcat install confuses me even more than if it was normal, and definitely frustrating that the logs could be anywhere. If we pretend I did have a normal install, are there any extra steps involved going from 5 to 6 that could be useful? Because going from 5.5.17 to 5.5.28 was extremely easy, following the steps I said in the original email. I do plan on experimenting with a vanilla install tomorrow (I get access tomorrow afternoon since everyone will be gone) but not sure how helpful it will be given the third party nature. Well you see, we're guessing also, because we have no idea what Smarts did to Tomcat. Although if they say that you could just download a new tomcat and unzip it to the same directory, then what they did might not be so bad. There is one element here that may be a cause of problems : To run Tomcat as a service under Windows, there are a couple of .exe programs being used. Under all versions of Tomcat 5.0 and 5.5, they are called tomcat5.exe and tomcat5w.exe. So when you upgraded before from 5.5.17 to 5.5.28, these names did not change. But with Tomcat 6, they are the same programs, but they are renamed to tomcat6.exe and tomcat6w.exe. But Smarts probably doesn't know that, so it may still try to call up tomcat5.exe to start Tomcat as a service. And who knows which one is running, when you say that the Service is running.. Maybe you could start at the beginning. Verify that the Tomcat service is running, and have a look : - with the Task Manager, and check which tomcat-like .exe program is really running - with a command window, - enter net start and check if you see a line in there mentioning tomcat (and if yes, paste it here so that we can see it too) - enter netstat -an and see there is a line with something like TCP 127.0.0.1:8080 ..LISTEN and then if it says by any chance TCP 127.0.0.1:8180 ..LISTEN instead, try with your browser to access http://localhost:8180 Come to think of it, enter netstat -an and then cut and paste here all the lines that start with TCP. I mean we can guess, but it is very energy-consuming, spiritually speaking. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: migration to 5.5.27
Timothy J Schumacher wrote: Hi, I am currently running tomcat 5.0.12 and want to upgrade to 5.5.27. snip / Please don't hijack threads. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
migration to 5.5.27
Hi, I am currently running tomcat 5.0.12 and want to upgrade to 5.5.27. I also have java 1.4 running on an old version of linux (redhat 7.3) and I have installed the compatibility package in my tomcat home directory. I can start and stop the server just fine. The trouble I am running into is in precompiling my jsp's. I use ant 1.6.1 and I edited my build.xml to change the jasper2 task to point to the new version of TC. Upon running my jspcompile task in ant I get a bunch of errors (I suspect these have something to do with log4j?). It looks like every jsp produces one of these: [jasper2] java.util.zip.ZipException: error in opening zip file [jasper2] at java.util.zip.ZipFile.open(Native Method) [jasper2] at java.util.zip.ZipFile.init(ZipFile.java:112) [jasper2] at java.util.zip.ZipFile.init(ZipFile.java:128) [jasper2] at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:903) [jasper2] at org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:126) [jasper2] at org.apache.tools.ant.AntClassLoader$ResourceEnumeration.init(AntClassLoader.java:88) [jasper2] at org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:869) [jasper2] at java.lang.ClassLoader.getResources(ClassLoader.java:812) [jasper2] at java.lang.ClassLoader.getResources(ClassLoader.java:808) [jasper2] at org.apache.commons.logging.LogFactory$4.run(LogFactory.java:1388) [jasper2] at java.security.AccessController.doPrivileged(Native Method) ... and with ant -v i get lines that look like this: Ignoring Exception java.util.zip.ZipException: error in opening zip file reading resource org/apache/log4j/Logger.class from /home/tschumacher/sandbox/XMan/Build/classes/SynchronizedQueue.class It looks like ant needs log4j but when I added it to the classpath for my jasper task it seemed to make no difference. I also tried ant -lib path-to-log4j jspcompile and I get a warning about not having configured a logger but same errors... Thanks! Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Sriganesh Ananth wrote: Hi Andre, I got Forbidden - You don't have permission to access /test/WEB-INF/web.xml on this server. Under httpd.conf, just before VirtualHost I have following to deny all from accessing WEB-INF folder. Httpd.conf configuration: # Globally deny access to the WEB-INF directory LocationMatch '.*WEB-INF.*' deny from all /LocationMatch VirtualHost … DocumentRoot /var/www/testapp Alias /test /var/www/testapp/ JkMount /*.do ajp13 JkMount /*.jsp ajp13 /VirtualHost Do you still smell something fishy here? Ok, that LocationMatch (which you did not mention before, and which still smells fishy if it is really outside of your VirtualHost section), makes things somewhat better, although it still smells like fish. By the way, as written, that is a *very expensive* match, and one that will also match things like /any/path/even/NOT-WEB-INF/abc.gif /any/path/even/WEB-INFORMATION-DEPARTMENT/abc.gif and under Windows, will not stop people getting to your WEB-INF like so : http://192.168.1.23/test/web-inf/web.xml What also still smells fishy is the line Alias /test /var/www/testapp/ Why is it there ? What does it achieve, that the following 2 lines do not ? JkMount /*.do ajp13 JkMount /*.jsp ajp13 As a matter of fact, in the case of your configuration above, what does the Apache httpd front-end achieve, that Tomcat alone could not ? (I am not saying that you do not have good reasons to have an Apache httpd in front. Just that it is not very evident from the above why you need it. And if you don't need it, you would gain simplicity and efficiency by taking it out of the equation). I have a much longer and detailed explanation of my above comments ready for you if you are interested, but if your purpose was simply to get this running on some test system, then it may not be worth it. But at least read this http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html (the section entitled Configuring Apache to serve static web application files) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/24/2009 3:27 AM, André Warnier wrote: Sriganesh Ananth wrote: What also still smells fishy is the line Alias /test /var/www/testapp/ Why is it there ? What does it achieve, that the following 2 lines do not ? JkMount /*.do ajp13 JkMount /*.jsp ajp13 Static content? I have a much longer and detailed explanation of my above comments ready for you if you are interested, but if your purpose was simply to get this running on some test system, then it may not be worth it. But at least read this http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html (the section entitled Configuring Apache to serve static web application files) My preferred Apache httpd configuration is something like this: Alias /contextName /path/to/webapp/root JkStripSession On JkMount /contextName/*.do myWorker JkMount /contextName/*.jsp myWorker Location /diagnosis Order Allow,Deny Allow from all SetEnvIf X-Moz prefetch x_moz_prefetch Deny from env=x_moz_prefetch ErrorDocument 403 /contextName/forbidden.html ErrorDocument 404 /contextName/not_found.html ErrorDocument 500 /contextName/down.html # This one means 'servlet unavailable' ErrorDocument 503 /contextName/down.html /Location # Directories above this one should already be protected # elsewhere. MAKE SURE THEY ARE. Directory /path/to/webapp/root Order allow,deny Allow from all Options -Indexes DirectoryIndex index.html /Directory Directory /path/to/webapp/root/WEB-INF Order deny,allow Deny from all /Directory Directory /path/to/webapp/root/META-INF Order deny,allow Deny from all /Directory - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknxyd4ACgkQ9CaO5/Lv0PBorwCeIY545r0PJNLylxOSP9Ydi8og zA0AoL3+bbwxxUw/gd2SyG83/tJtJH6W =za// -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Hi I am experiencing a very peculiar issue when migrating from Apache Tomcat 4.1.x (Apache 1.3.27) to 5.5.23 (Apache 2.2.3) on Red hat Linux 5. The issue is Tomcat 5.5.x looks for a servlet file under server’s physical file system and reporting HTTP 404 error rather than going to the servlet mapping in web.xml. Tomcat 4.1.x doesn’t have this problem. I am searching all support group from past many weeks and still not able to resolve this issue. Application Structure: ROOT --testapp ---test index.html WEB-INF ---classes ---HelloServlet.class WEB-INF\web.xml configuration: servlet servlet-namehello/servlet-name servlet-classHelloServlet/servlet-class /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/test/hello.do/url-pattern /servlet-mapping Httpd.conf configuration: VirtualHost … DocumentRoot /var/www/testapp Alias /test /var/www/testapp/ JkMount /*.do ajp13 JkMount /*.jsp ajp13 /VirtualHost When I browse http://192.168.1.23/test/hello.do I get “HTTP Status 404 - /test/hello.do, the requested resource (/test/hello.do) is not available”. In my synopsis when Tomcat 5.5.x looks at the URL it is first going to a folder called ‘test’ and looking for a file called ‘hello.do’ in the folder rather than going into web.xml first. The above structure and configuration just works just fine on Tomcat 4.1.x. Also, I didn’t see any mention of this change on the Tomcat change logs. I would really appreciate your help in resolving this issue on Tomcat 5.5.x. Please Note: 1. If I change the url-pattern to url-pattern/hello.do/url-pattern in web.xml the servlet call works but changing the entire application this way is beyond my scope. 2. I have tried a work around by defining sub-context in the server.xml, this works fine except that the sessions defined in parent app and sub-context app is not accessible to each other since both are in the different contexts. I know that there are mechanisms available to share the session between the different contexts but it is again beyond my scope to change the application in this pattern. Thank you for your help in advance. Regards Sriganesh - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
From: Sriganesh Ananth [mailto:sriganesh.anant...@gmail.com] Subject: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml The issue is Tomcat 5.5.x looks for a servlet file under server's physical file system and reporting HTTP 404 error rather than going to the servlet mapping in web.xml. Post your server.xml file and the file containing the Context element for your webapp. If you made the mistake of blindly copying your 4.1 server.xml file to 5.5, throw away what you did and start over. There are numerous syntactic and semantic changes in 5.5 that are best handled by modifying the default 5.5 server.xml file to suit your requirements rather than trying to modify a 4.1 server.xml file to work with 5.5. I suspect you have an invalid Host and Context combination, but only if you post that can we tell for sure. - 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
Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Chuck, Thank you for your reply. I didn't copy 4.1 server.xml but instead build it fresh on 5.5 provided server.xml. Following is the server.xml (removed comments and commented lines) --- Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ Listener className=org.apache.jk.config.ApacheConfig modJk=/usr/lib64/httpd/modules/mod_jk.so workersConfig=/etc/httpd/conf/workers.properties / GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina !-- Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 enableLookups=false redirectPort=8443 protocol=AJP/1.3 / !-- Define the top level container in our container hierarchy -- Engine name=Catalina defaultHost=localhost !-- This Realm uses the UserDatabase configured in the global JNDI resources under the key UserDatabase. Any edits that are performed against this UserDatabase are immediately available for use by the Realm. -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !--Added by Sriganesh on 04/16-- !-- Define the virtual host -- Host name=192.168.1.23 debug=1 appBase=/var/www/testapp unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=oss_access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=oss.com_log. suffix=.txt timestamp=true/ Context path= docBase= debug=0 reloadable=false crossContext=true Logger className=org.apache.catalina.logger.FileLogger prefix=oss_ROOT_log. suffix=.txt timestamp=true/ /Context /Host !--End editing-- !-- Define the default virtual host Note: XML Schema validation will not work with Xerces 2.2. -- Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service /Server Following is the context.xml content: --- Context !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource !-- Uncomment this to disable session persistence across Tomcat restarts -- !-- Manager pathname= / -- /Context Thank you again for your help. Regards Sriganesh On Thu, Apr 23, 2009 at 12:35 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Sriganesh Ananth [mailto:sriganesh.anant...@gmail.com] Subject: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml The issue is Tomcat 5.5.x looks for a servlet file under server's physical file system and reporting HTTP 404 error rather than going to the servlet mapping in web.xml. Post your server.xml file and the file containing the Context element for your webapp. If you made the mistake of blindly copying your 4.1 server.xml file to 5.5, throw away what you did and start over. There are numerous syntactic and semantic changes in 5.5 that are best handled by modifying the default 5.5 server.xml file to suit your requirements rather than trying to modify a 4.1 server.xml file to work with 5.5. I suspect you have an invalid Host and Context combination, but only if you post that can we tell for sure. - 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
RE: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
From: Sriganesh Ananth [mailto:sriganesh.anant...@gmail.com] Subject: Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml Host name=192.168.1.23 debug=1 appBase=/var/www/testapp unpackWARs=true The above is wrong; the appBase should be /var/www. Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=oss.com_log. suffix=.txt timestamp=true/ Logger elements are not used in 5.5; remove both of them. Context path= docBase= debug=0 reloadable=false crossContext=true The above is wrong; docBase should be testapp; you must never have an empty docBase. A bug in prior levels of Tomcat occasionally caused something useful to happen when you did that, but it was an accident. Note that putting Context elements in server.xml is strongly discouraged; the proper location is in a webapp's META-INF/context.xml file, or in conf/Catalina/[host]/[appName].xml. Also, if you're defining the default webapp, it should be named ROOT. Read the Tomcat docs: http://tomcat.apache.org/tomcat-5.5-doc/config/context.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
Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Chuck, you rock!!! I changed the appBase to /var/www for Host, added testapp in the Context docBase and restarted the tomcat and it worked!!! I will work on migrating the Context elements to the META-INF folder as suggested by you. Again, thank you very much for your help on this and you have have a wonderful day. Regards Sriganesh On Thu, Apr 23, 2009 at 1:06 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Sriganesh Ananth [mailto:sriganesh.anant...@gmail.com] Subject: Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml Host name=192.168.1.23 debug=1 appBase=/var/www/testapp unpackWARs=true The above is wrong; the appBase should be /var/www. Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=oss.com_log. suffix=.txt timestamp=true/ Logger elements are not used in 5.5; remove both of them. Context path= docBase= debug=0 reloadable=false crossContext=true The above is wrong; docBase should be testapp; you must never have an empty docBase. A bug in prior levels of Tomcat occasionally caused something useful to happen when you did that, but it was an accident. Note that putting Context elements in server.xml is strongly discouraged; the proper location is in a webapp's META-INF/context.xml file, or in conf/Catalina/[host]/[appName].xml. Also, if you're defining the default webapp, it should be named ROOT. Read the Tomcat docs: http://tomcat.apache.org/tomcat-5.5-doc/config/context.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 migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Sriganesh Ananth wrote: Chuck, you rock!!! That part, I tend to agree. I changed the appBase to /var/www for Host, added testapp in the Context docBase and restarted the tomcat and it worked!!! But this part, and what follows : Httpd.conf configuration: VirtualHost … DocumentRoot /var/www/testapp Alias /test /var/www/testapp/ JkMount /*.do ajp13 JkMount /*.jsp ajp13 /VirtualHost I definitely find bizarre. Can you try the following URL in your browser : http://192.168.1.23/test/WEB-INF/web.xml and let us know what you get ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat migration 4.1.3 to 5.5.23: Tomcat5.5 searching servlet file in file system and reporting 404 error rather mapping in web.xml
Hi Andre, I got Forbidden - You don't have permission to access /test/WEB-INF/web.xml on this server. Under httpd.conf, just before VirtualHost I have following to deny all from accessing WEB-INF folder. Httpd.conf configuration: # Globally deny access to the WEB-INF directory LocationMatch '.*WEB-INF.*' deny from all /LocationMatch VirtualHost … DocumentRoot /var/www/testapp Alias /test /var/www/testapp/ JkMount /*.do ajp13 JkMount /*.jsp ajp13 /VirtualHost Do you still smell something fishy here? Regards Sriganesh On Thu, Apr 23, 2009 at 2:41 PM, André Warnier a...@ice-sa.com wrote: Sriganesh Ananth wrote: Chuck, you rock!!! That part, I tend to agree. I changed the appBase to /var/www for Host, added testapp in the Context docBase and restarted the tomcat and it worked!!! But this part, and what follows : Httpd.conf configuration: VirtualHost … DocumentRoot /var/www/testapp Alias /test /var/www/testapp/ JkMount /*.do ajp13 JkMount /*.jsp ajp13 /VirtualHost I definitely find bizarre. Can you try the following URL in your browser : http://192.168.1.23/test/WEB-INF/web.xml and let us know what you get ? - 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: Migration from Tomcat 4.1 to 6.0 Urgent
Chris/Chuck, You are probably right about httpd. Please see the attached images for details. The reason why I thought I had a 2.2 application is because whenever I shutdown the 2.2 service, the main web site running on port 80 would not launch. Please excuse my naiveness about our configuration. I just recently inherited this system and was not provide any documentation.. so I am trying to figure it all out. Anyway, I only need to keep the tomcat 6.0 version of the tomcat. Can you please explain how I should configure httpd to work with the tomcat 6.0 version of the application, not 4.1. Chris provided me with the following instructions. It seems like I have to use mod_proxy_http or mod_proxy_ajp. Can you please provide me step by step instruction on how I should change my existing configuration to work with the newer application? Thank you so so much. God Bless... Rashid, On 4/7/2009 5:08 PM, Rashid Malik wrote: Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. Aah, you didn't mention that. Only one process may bind to a particular interface/port combination. In your case, port 80 is already taken (by Tomcat 4.1). If you want both Tomcat 4.1 ans 6.0 to appear to be using port 80, you will need to put another piece of software out in front in order to play traffic cop and properly route the requests to the appropriate server (app on TC4.1 versus app on TC6.0). Apache httpd is a popular choice for accomplishing this. You will have to: 1. Change Tomcat 4.1's configuration so that the HTTP port is something /other/ than port 80 (8080 is a popular choice) 2. Change Tomcat 6.0's configuration so that the HTTP port is something /other/ than port 80 and 8080 (8081?) 3. Install Apache httpd and have it listen on port 80 4. Configure httpd to send the appropriate requests to the appropriate back-end server To accomplish #4, you will need to use either mod_proxy_http, mod_proxy_ajp (both built-into Apache httpd 2.2.x) or mod_jk (which is a separate download). There is a lot of documentation for using mod_jk here: http://tomcat.apache.org/connectors-doc/ If you use mod_proxy_http, you'll need to do: ProxyPass /appA http://localhost:8080/appA ProxyPass /appB http://localhost:8081/appB That should be enough to get you started. - -chris Christopher Schultz ch...@christopherschultz.net 4/7/2009 6:03:42 pm -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 5:45 PM, Rashid Malik wrote: What I mean here is that I have three 3 installations of tomcat not 2. How many total web applications do you have? Do any of them have any requirements for which Tomcat version on which they are running? It sounds like the answer is I have 3 webapps and at least one of them requires Tomcat 6.0. If there are no other constraints, then just move all your webapps to Tomcat 6.0, uninstall Tomcat 4.1, and change Tomcat 6.0's Connector to port=80 as I said previously. There is tomcat 2.2 application (using port 80) As Chuck suggests, that is probably Apache httpd, which might actually make things easier. If this is the case, you have not correctly configured httpd to support your new application. Go into httpd's configuration and find out where your other application is configured. Read and /understand/ the configuration before you start changing things. Reading that configuration plus the config reference I already posted should clear a lot of things up. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbzb4ACgkQ9CaO5/Lv0PCgngCeJLFU7QsoPwisTu7EVwvLHJ+g 3aEAoKgI0amw4JfW1BU0+5fbmG1rRO4G =1bQY -END PGP SIGNATURE- - 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: Migration from Tomcat 4.1 to 6.0
http://httpd.apache.org/docs/2.2/ Read Compiling and Installing section You will need to undertand the modules and directives of several modules. You will find in the Apache site instructions for mod_proxy, but if you decide mod_jk then here are the instructions http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html http://www.linuxjournal.com/article/8561 Can you please provide me step by step instruction... Don't expect the people in the list to do your work. Research, read, experiment! Then come back with specific questions. -Jorge -Original Message- From: Rashid Malik [mailto:rma...@dhmh.state.md.us] Sent: Wednesday, April 08, 2009 10:48 AM To: Tomcat Users List Subject: Re: Migration from Tomcat 4.1 to 6.0 Urgent Chris/Chuck, You are probably right about httpd. Please see the attached images for details. The reason why I thought I had a 2.2 application is because whenever I shutdown the 2.2 service, the main web site running on port 80 would not launch. Please excuse my naiveness about our configuration. I just recently inherited this system and was not provide any documentation.. so I am trying to figure it all out. Anyway, I only need to keep the tomcat 6.0 version of the tomcat. Can you please explain how I should configure httpd to work with the tomcat 6.0 version of the application, not 4.1. Chris provided me with the following instructions. It seems like I have to use mod_proxy_http or mod_proxy_ajp. Can you please provide me step by step instruction on how I should change my existing configuration to work with the newer application? Thank you so so much. God Bless... Rashid, On 4/7/2009 5:08 PM, Rashid Malik wrote: Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. Aah, you didn't mention that. Only one process may bind to a particular interface/port combination. In your case, port 80 is already taken (by Tomcat 4.1). If you want both Tomcat 4.1 ans 6.0 to appear to be using port 80, you will need to put another piece of software out in front in order to play traffic cop and properly route the requests to the appropriate server (app on TC4.1 versus app on TC6.0). Apache httpd is a popular choice for accomplishing this. You will have to: 1. Change Tomcat 4.1's configuration so that the HTTP port is something /other/ than port 80 (8080 is a popular choice) 2. Change Tomcat 6.0's configuration so that the HTTP port is something /other/ than port 80 and 8080 (8081?) 3. Install Apache httpd and have it listen on port 80 4. Configure httpd to send the appropriate requests to the appropriate back-end server To accomplish #4, you will need to use either mod_proxy_http, mod_proxy_ajp (both built-into Apache httpd 2.2.x) or mod_jk (which is a separate download). There is a lot of documentation for using mod_jk here: http://tomcat.apache.org/connectors-doc/ If you use mod_proxy_http, you'll need to do: ProxyPass /appA http://localhost:8080/appA ProxyPass /appB http://localhost:8081/appB That should be enough to get you started. - -chris Christopher Schultz ch...@christopherschultz.net 4/7/2009 6:03:42 pm -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 5:45 PM, Rashid Malik wrote: What I mean here is that I have three 3 installations of tomcat not 2. How many total web applications do you have? Do any of them have any requirements for which Tomcat version on which they are running? It sounds like the answer is I have 3 webapps and at least one of them requires Tomcat 6.0. If there are no other constraints, then just move all your webapps to Tomcat 6.0, uninstall Tomcat 4.1, and change Tomcat 6.0's Connector to port=80 as I said previously. There is tomcat 2.2 application (using port 80) As Chuck suggests, that is probably Apache httpd, which might actually make things easier. If this is the case, you have not correctly configured httpd to support your new application. Go into httpd's configuration and find out where your other application is configured. Read and /understand/ the configuration before you start changing things. Reading that configuration plus the config reference I already posted should clear a lot of things up. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbzb4ACgkQ9CaO5/Lv0PCgngCeJLFU7QsoPwisTu7EVwvLHJ+g 3aEAoKgI0amw4JfW1BU0+5fbmG1rRO4G =1bQY -END PGP SIGNATURE- - 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
Migration from Tomcat 4.1 to 6.0 Urgent
To whom it may concern: I am new to Tomcat and anyone's help will be greatly appreciated. I have recently deployed an application in Tomcat 6.0 that works flawlessly. However, previous version of this same application was running on Tomcat 4.1. My issue is that I want to basically replace the existing 4.1 webapp with the newly updated 6.0 webapp. Also, I want the URLs to stay the same for the new site as they were in the previous version. The reason is the there is a main page that has the following link on it to connect to MyWebApp. To give you an example, the URL to get to the application in 4.1 is: http://localhost/MyWebAPP/ However, after shutting down tomcat 4.1, installing and configuring tomcat 6.0, I can use the new web app only using the following URL. Taking out the port number 8080 from the following URL returns page not found. I want to basically uninstall/undeploy the 4.1 version and replace it with the 6.0 version with everything working exactly the same. This newer application required Tomcat 6.0 and Java 1.6. Please note that the 4.1 manager does not work for some reason. http://localhost:8080/MyWebAPP/ P.s. Also, is there a way to change the port from 8080 to something else? Rashid Malik GIS Programmer Analyst Certified Oracle DBA Community Health Administration Maryland Department of Health and Mental Hygiene 201 W. Preston St. Baltimore, MD 21201 rma...@dhmh.state.md.us (410) 767-1024 (410) 333-7545 fax ( mailto:rma...@dhmh.state.md.us ) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat 4.1 to 6.0 Urgent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 4:45 PM, Rashid Malik wrote: To give you an example, the URL to get to the application in 4.1 is: http://localhost/MyWebAPP/ However, after shutting down tomcat 4.1, installing and configuring tomcat 6.0, I can use the new web app only using the following URL. http://localhost:8080/MyWebAPP/ Your new 6.0 configuration does not match your old 4.1 configuration. Check server.xml for an active (that is, not commented-out) Connector element. It should have the port=8080 attribute. Just change this to port=80 and you will no longer need to specify the port number. Taking out the port number 8080 from the following URL returns page not found. That's because the port number is required if your server is not listening on port 80 (the default port for HTTP). Please note that the 4.1 manager does not work for some reason. You should use the 6.0 manager with Tomcat 6.0. The 4.1 manager will be incompatible with Tomcat 6.0. P.s. Also, is there a way to change the port from 8080 to something else? See above. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbveAACgkQ9CaO5/Lv0PAybgCgliNBGcU7ul+gA6kwat/KErci XnoAn2v/4+a0hPAjDhcja9QrG+9DDumL =k/AZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat 4.1 to 6.0 Urgent
Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. that website is already using port 80. On that page, there is a link that connects to http://localhost/MyWebAPP/ . If I use the older version of this site (4.1), it works. However, using a 6.0 version only works with this URL: http://localhost:8080/MyWebAPP/ . Please help Christopher Schultz ch...@christopherschultz.net 4/7/2009 4:56 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 4:45 PM, Rashid Malik wrote: To give you an example, the URL to get to the application in 4.1 is: http://localhost/MyWebAPP/ However, after shutting down tomcat 4.1, installing and configuring tomcat 6.0, I can use the new web app only using the following URL. http://localhost:8080/MyWebAPP/ Your new 6.0 configuration does not match your old 4.1 configuration. Check server.xml for an active (that is, not commented-out) Connector element. It should have the port=8080 attribute. Just change this to port=80 and you will no longer need to specify the port number. Taking out the port number 8080 from the following URL returns page not found. That's because the port number is required if your server is not listening on port 80 (the default port for HTTP). Please note that the 4.1 manager does not work for some reason. You should use the 6.0 manager with Tomcat 6.0. The 4.1 manager will be incompatible with Tomcat 6.0. P.s. Also, is there a way to change the port from 8080 to something else? See above. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbveAACgkQ9CaO5/Lv0PAybgCgliNBGcU7ul+gA6kwat/KErci XnoAn2v/4+a0hPAjDhcja9QrG+9DDumL =k/AZ -END PGP SIGNATURE- - 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: Migration from Tomcat 4.1 to 6.0 Urgent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 5:08 PM, Rashid Malik wrote: Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. Aah, you didn't mention that. Only one process may bind to a particular interface/port combination. In your case, port 80 is already taken (by Tomcat 4.1). If you want both Tomcat 4.1 ans 6.0 to appear to be using port 80, you will need to put another piece of software out in front in order to play traffic cop and properly route the requests to the appropriate server (app on TC4.1 versus app on TC6.0). Apache httpd is a popular choice for accomplishing this. You will have to: 1. Change Tomcat 4.1's configuration so that the HTTP port is something /other/ than port 80 (8080 is a popular choice) 2. Change Tomcat 6.0's configuration so that the HTTP port is something /other/ than port 80 and 8080 (8081?) 3. Install Apache httpd and have it listen on port 80 4. Configure httpd to send the appropriate requests to the appropriate back-end server To accomplish #4, you will need to use either mod_proxy_http, mod_proxy_ajp (both built-into Apache httpd 2.2.x) or mod_jk (which is a separate download). There is a lot of documentation for using mod_jk here: http://tomcat.apache.org/connectors-doc/ If you use mod_proxy_http, you'll need to do: ProxyPass /appA http://localhost:8080/appA ProxyPass /appB http://localhost:8081/appB That should be enough to get you started. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbw/sACgkQ9CaO5/Lv0PA/TgCfUuclAcTXu9aQwp7Ov2qSK7I5 nacAoK2ple5RH6My3jwaTIeQBXB88caf =rcZe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat 4.1 to 6.0 Urgent
Hello Chris, Thanks for your quick response. What you said makes sense to me but let me clarify my situation further. Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. What I mean here is that I have three 3 installations of tomcat not 2. There is tomcat 2.2 application (using port 80) that is being used for a very basic web page that has nothing but URLs to various parts of the application that is being run on Tomcat 6.0. This tomcat 6.0 application is running on port 8080. The older version of this application was using tomcat 4.1 and listening on port 8080 also. However, after upgrading the application to 6.0, I shutdown the tomcat 4.1 application. From the tomcat 2.2 homepage, I can just click the link that will take me directly to http://localhost/MyWebAPP/ However, after shutting down tomcat 4.1, installing and configuring tomcat 6.0, I can use the new web app only using the following URL. http://localhost:8080/MyWebAPP/ Do I still need to do what you mentioned in your previous email or should there be a different approach. I can completely uninstall tomcat 4.1 if I have to. Thanks, Rashid Christopher Schultz ch...@christopherschultz.net 4/7/2009 5:22 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 5:08 PM, Rashid Malik wrote: Hi, I changed port 8080 to 80 and I get page not found error. Please note that I have another website that is running on an older version of tomcat. Aah, you didn't mention that. Only one process may bind to a particular interface/port combination. In your case, port 80 is already taken (by Tomcat 4.1). If you want both Tomcat 4.1 ans 6.0 to appear to be using port 80, you will need to put another piece of software out in front in order to play traffic cop and properly route the requests to the appropriate server (app on TC4.1 versus app on TC6.0). Apache httpd is a popular choice for accomplishing this. You will have to: 1. Change Tomcat 4.1's configuration so that the HTTP port is something /other/ than port 80 (8080 is a popular choice) 2. Change Tomcat 6.0's configuration so that the HTTP port is something /other/ than port 80 and 8080 (8081?) 3. Install Apache httpd and have it listen on port 80 4. Configure httpd to send the appropriate requests to the appropriate back-end server To accomplish #4, you will need to use either mod_proxy_http, mod_proxy_ajp (both built-into Apache httpd 2.2.x) or mod_jk (which is a separate download). There is a lot of documentation for using mod_jk here: http://tomcat.apache.org/connectors-doc/ If you use mod_proxy_http, you'll need to do: ProxyPass /appA http://localhost:8080/appA ProxyPass /appB http://localhost:8081/appB That should be enough to get you started. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbw/sACgkQ9CaO5/Lv0PA/TgCfUuclAcTXu9aQwp7Ov2qSK7I5 nacAoK2ple5RH6My3jwaTIeQBXB88caf =rcZe -END PGP SIGNATURE- - 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: Migration from Tomcat 4.1 to 6.0 Urgent
From: Rashid Malik [mailto:rma...@dhmh.state.md.us] Subject: Re: Migration from Tomcat 4.1 to 6.0 Urgent There is tomcat 2.2 application (using port 80) There was never any Tomcat 2.2 release. You may actually have httpd on port 80, since there is a 2.2 version of that. httpd usually communicates with Tomcat via port 8009 using mod_jk; is that what's really going on? What you have described so far as your existing installation is not physically possible. - 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
Re: Migration from Tomcat 4.1 to 6.0 Urgent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rashid, On 4/7/2009 5:45 PM, Rashid Malik wrote: What I mean here is that I have three 3 installations of tomcat not 2. How many total web applications do you have? Do any of them have any requirements for which Tomcat version on which they are running? It sounds like the answer is I have 3 webapps and at least one of them requires Tomcat 6.0. If there are no other constraints, then just move all your webapps to Tomcat 6.0, uninstall Tomcat 4.1, and change Tomcat 6.0's Connector to port=80 as I said previously. There is tomcat 2.2 application (using port 80) As Chuck suggests, that is probably Apache httpd, which might actually make things easier. If this is the case, you have not correctly configured httpd to support your new application. Go into httpd's configuration and find out where your other application is configured. Read and /understand/ the configuration before you start changing things. Reading that configuration plus the config reference I already posted should clear a lot of things up. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbzb4ACgkQ9CaO5/Lv0PCgngCeJLFU7QsoPwisTu7EVwvLHJ+g 3aEAoKgI0amw4JfW1BU0+5fbmG1rRO4G =1bQY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
I am migrating from 5.5.23 on Windows to 6.0.18. I have installed the Windows Service binary download and can start up the server fine with the installation defaults. I then point CATALINA_BASE to my actual tomcat base directory that I use for my project with 5.5.23 and I get the following: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:215) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:390) What other changes should I make after installation? With 5.5.23 that was all that was necessary, is there another step to use a custom catalina base with 6.x? Are they not backwards-compatible in this sense? Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
Hi Dan You need to set CATALINA_HOME variable pointingo to your installation directory. Flavio regards Dan d...@tipjarawards.com gravou em 21/01/2009 14:27:27: I am migrating from 5.5.23 on Windows to 6.0.18. I have installed the Windows Service binary download and can start up the server fine with the installation defaults. I then point CATALINA_BASE to my actual tomcat base directory that I use for my project with 5.5.23 and I get the following: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:215) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:390) What other changes should I make after installation? With 5.5.23 that was all that was necessary, is there another step to use a custom catalina base with 6.x? Are they not backwards-compatible in this sense? Thanks, Dan - 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: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
CATALINA_HOME is pointing there, that is the default from the installtion. Here is the view of the tomcat service params: -Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat 6.0.18 -Dcatalina.base=c:\dev\tomcat -Djava.endorsed.dirs=C:\Program Files\Apache Software Foundation\Tomcat 6.0.18\endorsed -Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\Tomcat 6.0.18\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files\Apache Software Foundation\Tomcat 6.0.18\conf\logging.properties Thanks, Dan -Original Message- From: Flavio Crispim [mailto:flavio.cris...@sulamerica.com.br] Sent: January-21-09 11:46 AM To: Tomcat Users List Subject: Re: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina Hi Dan You need to set CATALINA_HOME variable pointingo to your installation directory. Flavio regards Dan d...@tipjarawards.com gravou em 21/01/2009 14:27:27: I am migrating from 5.5.23 on Windows to 6.0.18. I have installed the Windows Service binary download and can start up the server fine with the installation defaults. I then point CATALINA_BASE to my actual tomcat base directory that I use for my project with 5.5.23 and I get the following: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:215) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:390) What other changes should I make after installation? With 5.5.23 that was all that was necessary, is there another step to use a custom catalina base with 6.x? Are they not backwards-compatible in this sense? Thanks, Dan - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
From: Flavio Crispim [mailto:flavio.cris...@sulamerica.com.br] Subject: Re: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina You need to set CATALINA_HOME variable pointingo to your installation directory. That's not useful in any way. The OP is running Tomcat as Windows service, so environment variables are ignored. Any necessary settings (including location of the Tomcat code) must be done via the tomcat6w.exe program. Note that once the service is installed, the location of the tomcat6.exe program *cannot* be changed, but catalina.home and catalina.base system properties can. If you want to run tomcat6.exe from a different location, you'll need to download the .zip (not .exe) package, install it where you want, then use the service.bat script to create the service. - 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
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
From: Dan [mailto:d...@tipjarawards.com] Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina -Dcatalina.base=c:\dev\tomcat And what's under c:\dev\tomcat? - 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
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
I haven't changed anything from the default installation. I did the following: 1. Installed 6.0.18 as windows service 2. Launch the service after a successful installation, no problems it starts. Tried the tomcat6.exe directly, no problems. 3. Click the service tray icon to change the -Dcatalina.base directory to c:\dev\tomcat 4. Restart the service, it fails with the classnotfound exception as noted, same if I use tomcat6.exe. The c:\dev\tomcat contains my webapps etc. so it has a bin/conf/logs/shared/webapps/ directories. I'm really stumped on this one as I've used tomcat for years with no problems. Is there a CLASSPATH environment variable that needs to exist? Thanks, Dan -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: January-21-09 12:16 PM To: Tomcat Users List Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina From: Dan [mailto:d...@tipjarawards.com] Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina -Dcatalina.base=c:\dev\tomcat And what's under c:\dev\tomcat? - 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: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
2009/1/21 Dan d...@tipjarawards.com: I haven't changed anything from the default installation. I did the following: 1. Installed 6.0.18 as windows service 2. Launch the service after a successful installation, no problems it starts. Tried the tomcat6.exe directly, no problems. 3. Click the service tray icon to change the -Dcatalina.base directory to c:\dev\tomcat 4. Restart the service, it fails with the classnotfound exception as noted, same if I use tomcat6.exe. The c:\dev\tomcat contains my webapps etc. so it has a bin/conf/logs/shared/webapps/ directories. I'm really stumped on this one as I've used tomcat for years with no problems. Is there a CLASSPATH environment variable that needs to exist? You cannot use pre-existing 5.5 configuration to run Tomcat 6.0. You must copy the one from TC 6.0 installation and tune it accordingly. Your specific problem is caused by the differences in catalina.properties files (*.loader paths are different), but most of other configuration files are also different between versions (though similar). CLASSPATH variable is not needed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
From: Dan [mailto:d...@tipjarawards.com] Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina The c:\dev\tomcat contains my webapps etc. so it has a bin/conf/logs/shared/webapps/ directories. The classloading hierarchy has changed in Tomcat 6; in particular, there is no shared directory anymore, but there is a lib directory (under catalina.home). If you're missing that, you'll get the exception you noted. If you simply expect your 5.5 conf/server.xml and conf/*.properties files to work in Tomcat 6, you're sadly mistaken. I'm really stumped on this one as I've used tomcat for years with no problems. Read the doc for the current level, not what you've used for years. Things change. Is there a CLASSPATH environment variable that needs to exist? NEVER, NEVER, NEVER set the CLASSPATH variable for Tomcat. (Besides, services ignore environment variables.) - 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
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
From: Caldarale, Charles R Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina If you simply expect your 5.5 conf/server.xml and conf/*.properties files to work in Tomcat 6, you're sadly mistaken. You might want to read this: http://tomcat.apache.org/migration.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
RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
I did read that but it didn't explicitly mention the change in the properties files etc. for classloader. I did expect the server to at least boot up with errors or something. Thanks for the help, will simply copy the installation default properties files to my base and should be good. Best, Dan -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: January-21-09 1:24 PM To: Caldarale, Charles R; Tomcat Users List Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina From: Caldarale, Charles R Subject: RE: Windows Migration 5.5.23 to 6.0.18 - java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina If you simply expect your 5.5 conf/server.xml and conf/*.properties files to work in Tomcat 6, you're sadly mistaken. You might want to read this: http://tomcat.apache.org/migration.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
Resin to Tomcat migration(context name is null)
I am trying to migrate my application from Resin to Tomcat 6.0.18. The application runs fine, but my application context name(the context is created) is coming as null in Tomcat. I tried using context.xml but still I am facing the same problem. In Resin the equivalent configuration in resin.conf looks like this web-app id=/Foo root-directory=webapps/Foo/ Can someone please let me know as to what exactly should I put in context.xml, where should I place it in Tomcat and should it be called context.xml or should it be renamed to my web application name? I tried with the following: Content of xml file(WAR file is foo.war under webapps folder): Context docBase=Foo WatchedResourceWEB-INF/web.xml/WatchedResource /Context Renamed the file from context.xml to foo.xml. Placed it in the default conf folder as well as conf/Catalina/localhost/foo.xml and conf/Catalina/localhost/context.xml Placed both context.xml as well as foo.xml in my web application META-INF folder. None of the above worked. Also is the context.xml or webappName.xml automcatically picked or should server.xml be informed of this file? -- Cheers, Abhi
Re: Resin to Tomcat migration(context name is null)
Abhi wrote: I am trying to migrate my application from Resin to Tomcat 6.0.18. The application runs fine, but my application context name(the context is created) is coming as null in Tomcat. How are you getting the context name? web-app id=/Foo root-directory=webapps/Foo/ Can someone please let me know as to what exactly should I put in context.xml, where should I place it in Tomcat and should it be called context.xml or should it be renamed to my web application name? In this case, you don't need a context.xml file. Just remove it from your webapp. If you had needed to use a context.xml file then it should located at META-INF/context.xml inside your WAR. Tomcat will automatically extract it to CATALINA_BASE/conf/engine name/host name/name of web app.xml For a WAR file foo.war in a default install this would be CATALINA_BASE/conf/Catalina/localhost/foo.xml Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resin to Tomcat migration(context name is null)
Thanks Mark. I am getting the context name using the session object session.getServletContext().getServletContextName() On Mon, Dec 1, 2008 at 5:23 PM, Mark Thomas [EMAIL PROTECTED] wrote: Abhi wrote: I am trying to migrate my application from Resin to Tomcat 6.0.18. The application runs fine, but my application context name(the context is created) is coming as null in Tomcat. How are you getting the context name? web-app id=/Foo root-directory=webapps/Foo/ Can someone please let me know as to what exactly should I put in context.xml, where should I place it in Tomcat and should it be called context.xml or should it be renamed to my web application name? In this case, you don't need a context.xml file. Just remove it from your webapp. If you had needed to use a context.xml file then it should located at META-INF/context.xml inside your WAR. Tomcat will automatically extract it to CATALINA_BASE/conf/engine name/host name/name of web app.xml For a WAR file foo.war in a default install this would be CATALINA_BASE/conf/Catalina/localhost/foo.xml Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Abhi
Re: Resin to Tomcat migration(context name is null)
This is an issue with the way getServletContextName() is implemented in Resin and Tomcat. In Tomcat this returns the display-name of the application where as in Resin it returns the URL prefix for the servlet context. Once I added a display name to my web application I am getting the context name in Tomcat. What I actually want is the URL prefix for the servlet context. The method to access this would be httpServletRequest.getContextPath(). But I want to access this in a filter. Does anybody know a container independent way to do this? On Mon, Dec 1, 2008 at 5:35 PM, Abhi [EMAIL PROTECTED] wrote: Thanks Mark. I am getting the context name using the session object session.getServletContext().getServletContextName() On Mon, Dec 1, 2008 at 5:23 PM, Mark Thomas [EMAIL PROTECTED] wrote: Abhi wrote: I am trying to migrate my application from Resin to Tomcat 6.0.18. The application runs fine, but my application context name(the context is created) is coming as null in Tomcat. How are you getting the context name? web-app id=/Foo root-directory=webapps/Foo/ Can someone please let me know as to what exactly should I put in context.xml, where should I place it in Tomcat and should it be called context.xml or should it be renamed to my web application name? In this case, you don't need a context.xml file. Just remove it from your webapp. If you had needed to use a context.xml file then it should located at META-INF/context.xml inside your WAR. Tomcat will automatically extract it to CATALINA_BASE/conf/engine name/host name/name of web app.xml For a WAR file foo.war in a default install this would be CATALINA_BASE/conf/Catalina/localhost/foo.xml Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Abhi -- Cheers, Abhi
Re: Resin to Tomcat migration(context name is null)
I apologize for not being clear. The code is in the init method.
On Mon, Dec 1, 2008 at 6:14 PM, André Warnier [EMAIL PROTECTED] wrote:
Abhi wrote:
This is an issue with the way getServletContextName() is implemented in
Resin and Tomcat. In Tomcat this returns the display-name of the
application
where as in Resin it returns the URL prefix for the servlet context. Once
I
added a display name to my web application I am getting the context name
in
Tomcat.
What I actually want is the URL prefix for the servlet context. The method
to access this would be httpServletRequest.getContextPath(). But I want to
access this in a filter.
And is there any reason why you cannot ?
I have this in a filter :
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) req;
StringBuffer callURL = request.getRequestURL();
...
}
(and I suppose you can also call request.getContextPath())
Does anybody know a container independent way to do this?
As far as I know, the above should be.
On Mon, Dec 1, 2008 at 5:35 PM, Abhi [EMAIL PROTECTED] wrote:
Thanks Mark.
I am getting the context name using the session object
session.getServletContext().getServletContextName()
On Mon, Dec 1, 2008 at 5:23 PM, Mark Thomas [EMAIL PROTECTED] wrote:
Abhi wrote:
I am trying to migrate my application from Resin to Tomcat 6.0.18. The
application runs fine, but my application context name(the context is
created) is coming as null in Tomcat.
How are you getting the context name?
web-app id=/Foo root-directory=webapps/Foo/
Can someone please let me know as to what exactly should I put in
context.xml, where should I place it in Tomcat and should it be called
context.xml or should it be renamed to my web application name?
In this case, you don't need a context.xml file. Just remove it from
your
webapp.
If you had needed to use a context.xml file then it should located at
META-INF/context.xml inside your WAR.
Tomcat will automatically extract it to CATALINA_BASE/conf/engine
name/host name/name of web app.xml
For a WAR file foo.war in a default install this would be
CATALINA_BASE/conf/Catalina/localhost/foo.xml
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cheers,
Abhi
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cheers,
Abhi
Re: Resin to Tomcat migration(context name is null)
Abhi wrote:
This is an issue with the way getServletContextName() is implemented in
Resin and Tomcat. In Tomcat this returns the display-name of the application
where as in Resin it returns the URL prefix for the servlet context. Once I
added a display name to my web application I am getting the context name in
Tomcat.
What I actually want is the URL prefix for the servlet context. The method
to access this would be httpServletRequest.getContextPath(). But I want to
access this in a filter.
And is there any reason why you cannot ?
I have this in a filter :
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) req;
StringBuffer callURL = request.getRequestURL();
...
}
(and I suppose you can also call request.getContextPath())
Does anybody know a container independent way to do this?
As far as I know, the above should be.
On Mon, Dec 1, 2008 at 5:35 PM, Abhi [EMAIL PROTECTED] wrote:
Thanks Mark.
I am getting the context name using the session object
session.getServletContext().getServletContextName()
On Mon, Dec 1, 2008 at 5:23 PM, Mark Thomas [EMAIL PROTECTED] wrote:
Abhi wrote:
I am trying to migrate my application from Resin to Tomcat 6.0.18. The
application runs fine, but my application context name(the context is
created) is coming as null in Tomcat.
How are you getting the context name?
web-app id=/Foo root-directory=webapps/Foo/
Can someone please let me know as to what exactly should I put in
context.xml, where should I place it in Tomcat and should it be called
context.xml or should it be renamed to my web application name?
In this case, you don't need a context.xml file. Just remove it from your
webapp.
If you had needed to use a context.xml file then it should located at
META-INF/context.xml inside your WAR.
Tomcat will automatically extract it to CATALINA_BASE/conf/engine
name/host name/name of web app.xml
For a WAR file foo.war in a default install this would be
CATALINA_BASE/conf/Catalina/localhost/foo.xml
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cheers,
Abhi
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resin to Tomcat migration(context name is null)
Abhi wrote: I apologize for not being clear. The code is in the init method. Tomcat 6.x implements Servlet API 2.5. There's appropiate ServletContext#getContextPath() method: http://tinyurl.com/5scpfz . So you can use it from Filter#init() without any problems. -- Mikolaj Rydzewski [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
