AW: Brand new to Tomcat
Hi Larry, of course you can add several Connector elements in server.xml. But notice that the value of the port attribute (not proxyPort) must be unique. Otherwise the second connector cannot be established at Tomcat startup. Regards Thomas -Ursprüngliche Nachricht- Von: Cohen, Laurence [mailto:lco...@novetta.com] Gesendet: Dienstag, 16. Juni 2015 17:33 An: users@tomcat.apache.org Betreff: Brand new to Tomcat Hi, I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine. In server.xml I can see the following connector line: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=443/ My first question is, can I add another connector line, proxying to port 80 as so: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=80/ Thanks, Larry Cohen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
On 16/06/2015 16:32, Cohen, Laurence wrote: Hi, I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine. In server.xml I can see the following connector line: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=443/ My first question is, can I add another connector line, proxying to port 80 as so: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=80/ No. The combination of address and port must be unique across all Connectors. To be more specific, you can't have more than one OS socket listening on an address/port combination Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Brand new to Tomcat
Hi, I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine. In server.xml I can see the following connector line: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=443/ My first question is, can I add another connector line, proxying to port 80 as so: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=80/ Thanks, Larry Cohen
Re: Brand new to Tomcat
Cohen, Laurence wrote: Hi, I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. I am going to do some guesswork here, and you'll tell us if I'm wrong. Presumably, considering what you are saying above, your actual setup may be : browser -- -- Apache httpd server front-end -- -- Tomcat -- -- webapp -- -- back-end postgres database So the browser clients actually connect to the Apache front-end server on port 80, and the front-end passes some or all of the requests to Tomcat in the background. (And the users never see a URL which mentions port 8007). Right/wrong ? If right, do you know what is the mechanism used in the front-end Apache httpd server, to connect to the back-end Tomcat service ? Specifically, are there any ProxyPass directives in the configuration of the front-end Apache server ? We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine. In server.xml I can see the following connector line: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=443/ My first question is, can I add another connector line, proxying to port 80 as so: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=80/ Thanks, Larry Cohen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
Am 16. Juni 2015 19:54:40 MESZ, schrieb Cohen, Laurence lco...@novetta.com: On the old instance, represented in these files by prodweb01, ssl.conf and rewrite.conf were included from httpd.conf On the new instance represented by testweb01, nss.conf and rewrite.conf are included from httpd.conf, and ssl.conf is no longer used. You'll see that there was an attempt to move all of the RewriteRules from the ssl.conf in the old instance to ProxyPass statements in nss.conf. I'm assuming you are correct that something is not correct with these rules. Did you attach files to your mail? The mailing list strips most attachments. You might be lucky attaching text files. Or you could strip out any comments and paste them inline. Our you put them somewhere else and send a link to the files. Regards, Felix Thanks, Larry Cohen On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence lco...@novetta.com wrote: I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
Yeah, I'm going to have to figure this out. If I paste the text in the email it will be very long. On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher felix.schumac...@internetallee.de wrote: Am 16. Juni 2015 19:54:40 MESZ, schrieb Cohen, Laurence lco...@novetta.com: On the old instance, represented in these files by prodweb01, ssl.conf and rewrite.conf were included from httpd.conf On the new instance represented by testweb01, nss.conf and rewrite.conf are included from httpd.conf, and ssl.conf is no longer used. You'll see that there was an attempt to move all of the RewriteRules from the ssl.conf in the old instance to ProxyPass statements in nss.conf. I'm assuming you are correct that something is not correct with these rules. Did you attach files to your mail? The mailing list strips most attachments. You might be lucky attaching text files. Or you could strip out any comments and paste them inline. Our you put them somewhere else and send a link to the files. Regards, Felix Thanks, Larry Cohen On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence lco...@novetta.com wrote: I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Brand new to Tomcat
From: Cohen, Laurence [mailto:lco...@novetta.com] Subject: Re: Brand new to Tomcat Sorry, I sent that last post before I sent this one. I'm assuming this is what you were meaning about top posting? I should just post after all previous posts? Yes, but trimming out the fluff (e.g., footers and any corporate-required disclaimers) while you're at it is also desirable. - 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: Brand new to Tomcat
*** nss.conf.testweb01 *** Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl.crl NSSPassPhraseDialog file:/etc/httpd/.password.conf #NSSPassPhraseDialog builtin NSSPassPhraseHelper /usr/sbin/nss_pcache NSSSessionCacheSize 1 NSSSessionCacheTimeout 100 NSSSession3CacheTimeout 86400 NSSRandomSeed startup builtin VirtualHost _default_:443 DocumentRoot /var/www/docroot NSSProxyCheckPeerCN Off NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on NSSRequireSafeNegotiation on NSSCipherSuite +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProxyCipherSuite +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP off ProxyPreserveHost On Location /dse-help #SSLRenegBufferSize 10486000 NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8007/dse-help https://testapp01.novetta.com:8007/dse-help ProxyPassReverse https://testapp01:8007/dse-help https://testapp01.novetta.com:8007/dse-help /Location Location /dse/opensearch NSSOptions +ExportCertData +StdEnvVars NSSVerifyClient require ProxyPass https://testapp01:8007/dse/opensearch https://testapp01.novetta.com:8007/dse/opensearch ProxyPassReverse https://testapp01:8007/dse/opensearch https://testapp01.novetta.com:8007/dse/opensearch /Location Location /dse/system_announcements/feed NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8007/dse/system_announcements/feed https://testapp01.novetta.com:8007/dse/system_announcements/feed ProxyPassReverse https://testapp01:8007/dse/system_announcements/feed https://testapp01.novetta.com:8007/dse/system_announcements/feed /Location Location /dse/feeds NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8007/dse/feeds https://testapp01.novetta.com:8007/dse/feeds ProxyPassReverse https://testapp01:8007/dse/feeds https://testapp01.novetta.com:8007/dse/feeds /Location Location /dse/web-services/publish?wsdl NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8007/dse/web-services/publish?wsdl https://testapp01.novetta.com:8007/dse/web-services/publish?wsdl ProxyPassReverse https://testapp01:8007/dse/web-services/publish?wsdl https://testapp01.novetta.com:8007/dse/web-services/publish?wsdl /Location Location /dse/web-services/emtopic?wsdl NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8007/dse/web-services/emtopic?wsdl https://testapp01.novetta.com:8007/dse/web-services/emtopic?wsdl ProxyPassReverse https://testapp01:8007/dse/web-services/emtopic?wsdl https://testapp01.novetta.com:8007/dse/web-services/emtopic?wsdl /Location Location /dse/web-services NSSOptions +ExportCertData +StdEnvVars NSSVerifyClient require ProxyPass https://testapp01:8007/dse/web-services https://testapp01.novetta.com:8007/dse/web-services ProxyPassReverse https://testapp01:8007/dse/web-services https://testapp01.novetta.com:8007/dse/web-services /Location Location /dse #SSLRenegBufferSize 5243 NSSVerifyClient optional NSSOptions +ExportCertData +StdEnvVars ProxyPass https://testapp01:8007/dse https://testapp01.novetta.com:8007/dse ProxyPassReverse https://testapp01:8007/dse https://testapp01.novetta.com:8007/dse /Location Location /juddiv3/services/security?wsdl NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8009/juddiv3/services/security?wsdl https://testapp01.novetta.com:8009/juddiv3/services/security?wsdl ProxyPassReverse https://testapp01:8007/juddiv3/services/security?wsdl https://testapp01.novetta.com:8007/juddiv3/services/security?wsdl /Location Location /juddiv3/services/inquiry?wsdl NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8009/juddiv3/services/inquiry?wsdl https://testapp01.novetta.com:8009/juddiv3/services/inquiry?wsdl ProxyPassReverse https://testapp01:8009/juddiv3/services/inquiry?wsdl https://testapp01.novetta.com:8009/juddiv3/services/inquiry?wsdl /Location Location /juddiv3/services/publish?wsdl NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass https://testapp01:8009/juddiv3/services/publish?wsdl https://testapp01.novetta.com:8009/juddiv3/services/publish?wsdl ProxyPassReverse https://testapp01:8009/juddiv3/services/publish?wsdl
Re: Brand new to Tomcat
On Tue, Jun 16, 2015 at 2:39 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Cohen, Laurence [mailto:lco...@novetta.com] Subject: Re: Brand new to Tomcat Sorry, I sent that last post before I sent this one. I'm assuming this is what you were meaning about top posting? I should just post after all previous posts? Yes, but trimming out the fluff (e.g., footers and any corporate-required disclaimers) while you're at it is also desirable. - 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 I apologize everyone. Are there some instructions that I'm supposed to have read through. I'd be happy to review anything that will provide direction so I can be a good community member. Thanks, Larry
RE: Brand new to Tomcat
From: Cohen, Laurence [mailto:lco...@novetta.com] Subject: Re: Brand new to Tomcat I apologize everyone. No apology needed - you're doing much better than many. Are there some instructions that I'm supposed to have read through. I'd be happy to review anything that will provide direction so I can be a good community member. The mailing list rules/guidelines are here: http://tomcat.apache.org/lists.html#tomcat-users - 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: Brand new to Tomcat
On the old instance, represented in these files by prodweb01, ssl.conf and rewrite.conf were included from httpd.conf On the new instance represented by testweb01, nss.conf and rewrite.conf are included from httpd.conf, and ssl.conf is no longer used. You'll see that there was an attempt to move all of the RewriteRules from the ssl.conf in the old instance to ProxyPass statements in nss.conf. I'm assuming you are correct that something is not correct with these rules. Thanks, Larry Cohen On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence lco...@novetta.com wrote: I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -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: Brand new to Tomcat
Am 16. Juni 2015 20:10:52 MESZ, schrieb Cohen, Laurence lco...@novetta.com: Yeah, I'm going to have to figure this out. If I paste the text in the email it will be very long. Maybe you could look for the changes yourself (diff might be your friend) and just paste the things that are different. In the SuSE package is a perl script, which claims to do the conversion from mod_ssl to mod_nss. You could try that on your original config files. By the way. It is considered bad style to top post in replies. Regards, Felix On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher felix.schumac...@internetallee.de wrote: Am 16. Juni 2015 19:54:40 MESZ, schrieb Cohen, Laurence lco...@novetta.com: On the old instance, represented in these files by prodweb01, ssl.conf and rewrite.conf were included from httpd.conf On the new instance represented by testweb01, nss.conf and rewrite.conf are included from httpd.conf, and ssl.conf is no longer used. You'll see that there was an attempt to move all of the RewriteRules from the ssl.conf in the old instance to ProxyPass statements in nss.conf. I'm assuming you are correct that something is not correct with these rules. Did you attach files to your mail? The mailing list strips most attachments. You might be lucky attaching text files. Or you could strip out any comments and paste them inline. Our you put them somewhere else and send a link to the files. Regards, Felix Thanks, Larry Cohen On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence lco...@novetta.com wrote: I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail:
Re: Brand new to Tomcat
On Tue, Jun 16, 2015 at 2:26 PM, Felix Schumacher felix.schumac...@internetallee.de wrote: Am 16. Juni 2015 20:10:52 MESZ, schrieb Cohen, Laurence lco...@novetta.com: Yeah, I'm going to have to figure this out. If I paste the text in the email it will be very long. Maybe you could look for the changes yourself (diff might be your friend) and just paste the things that are different. In the SuSE package is a perl script, which claims to do the conversion from mod_ssl to mod_nss. You could try that on your original config files. By the way. It is considered bad style to top post in replies. Regards, Felix On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher felix.schumac...@internetallee.de wrote: Am 16. Juni 2015 19:54:40 MESZ, schrieb Cohen, Laurence lco...@novetta.com: On the old instance, represented in these files by prodweb01, ssl.conf and rewrite.conf were included from httpd.conf On the new instance represented by testweb01, nss.conf and rewrite.conf are included from httpd.conf, and ssl.conf is no longer used. You'll see that there was an attempt to move all of the RewriteRules from the ssl.conf in the old instance to ProxyPass statements in nss.conf. I'm assuming you are correct that something is not correct with these rules. Did you attach files to your mail? The mailing list strips most attachments. You might be lucky attaching text files. Or you could strip out any comments and paste them inline. Our you put them somewhere else and send a link to the files. Regards, Felix Thanks, Larry Cohen On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence lco...@novetta.com wrote: I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -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: [OT] Brand new to Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 6/16/15 2:39 PM, Caldarale, Charles R wrote: From: Cohen, Laurence [mailto:lco...@novetta.com] Subject: Re: Brand new to Tomcat Sorry, I sent that last post before I sent this one. I'm assuming this is what you were meaning about top posting? I should just post after all previous posts? Yes, but trimming out the fluff (e.g., footers and any corporate-required disclaimers) while you're at it is also desirable. Yeah, I hate all those corporate disclaimers. 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. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgHIWAAoJEBzwKT+lPKRYcDgP/2nWkIEG17cGajqqtJMht9XO 8u2+4zBTK92ehKfzJ0wO7gLIpRene6hpJ3jatLQEyo5vfpxsKHkW38t7hojjJveD QX06FGrjNt5o0U6H2oPufaxaix1P92pSZMv2UD6TH/2/XFkm1tsw3sGUaoRlo7CH pNF1gCfwpk7daxq9uuE6fE2jxWyX0GsBVaKrtqj/aM8pP7lpUd2XvTsDXme9F44w TtTWESJ3uUK4shAu3tr0nJpdgs8UjC3my7QREKdOB1776jF3kKbtBLyjp0PZ12fS 8LhDAaibjztS740HVu5rjs5XGuRXuHIaOF2YlG7XFU/IwUf/MRYwGAxqTA8sNdAa Tr1DvaOU6H+9/YMXHQg8Jof6yThhvcMu4MfYy2ylGHirds4ciEf+QYv5I5F8xYJW SQoHC16WPM+7PFpdyQ9b+/CNRMTZO8Gg+X/Urb82/YEK2gPDdBW1ZlBTVgszk3pd IFjS3BmnK5VlKiEhfaZGmtcw5fNFbaRtsNBniHMDn1PLSi6FzcwcTp+Eurk7DOu7 9fy8TouE2tpYY0mR6l/tDlPH4j9shp58tAyRpXdBjj0RFlWQZ6HbEJ2QMfUpof+M 1A1c6Ytt8SZ5hMD90KmjYIP9j+oXbeJTg7uPdmXxKAVJjS3dX6lj/P+DVBW5gvGk 6Ez86RT8BR9bC+9qkvNH =XHit -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Thanks, Larry On Tue, Jun 16, 2015 at 12:06 PM, André Warnier a...@ice-sa.com wrote: Cohen, Laurence wrote: Hi, I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. I am going to do some guesswork here, and you'll tell us if I'm wrong. Presumably, considering what you are saying above, your actual setup may be : browser -- -- Apache httpd server front-end -- -- Tomcat -- -- webapp -- -- back-end postgres database So the browser clients actually connect to the Apache front-end server on port 80, and the front-end passes some or all of the requests to Tomcat in the background. (And the users never see a URL which mentions port 8007). Right/wrong ? If right, do you know what is the mechanism used in the front-end Apache httpd server, to connect to the back-end Tomcat service ? Specifically, are there any ProxyPass directives in the configuration of the front-end Apache server ? We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine. In server.xml I can see the following connector line: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=443/ My first question is, can I add another connector line, proxying to port 80 as so: Connector port=8007 protocol=HTTP/1.1 SSLEnabled=true executor=tomcatThreadPool connectionTimeout=60 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/opt/dse/keystores/keystore.tomcat keystorePass=changeit truststoreFile=/opt/dse/keystores/truststore.jks truststorePass=password proxyName=testweb01.novetta.com proxyPort=80/ Thanks, Larry Cohen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
I am most definitely confused. :-) I'm gathering and sanitizing configuration files now. Thanks, Larry On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurence, On 6/16/15 1:02 PM, Cohen, Laurence wrote: Thanks for everyone's response. to Andre' Warnier, yes. There are many ProxyPass statements in nss.conf on the Apache webserver. They appear to have taken the place of redirect statements in ssl.conf, which is no longer in use. I think you may be confused. mod_nss looks like a replacement for mod_ssl, which means it's only being used for connections coming *into* the Apache httpd process -- probably from clients. Yes, mod_ssl is also used to handle HTTPS going *out* through mod_proxy, but you say that's working, right? mod_ssl doesn't have any redirect configuration. If you had Redirect [something] then it was using mod_alias, and that has nothing to do with either mod_nss (nee mod_ssl) or whatever module you are using to proxy from httpd to Tomcat (probably mod_proxy_http). Your configuration assumption is correct, except that the users will connect to the webserver on port 80 and port 443, and it is invisible to them where they are going on the app server. Assuming that mod_nss can service mod_proxy_http just as mod_ssl was able to in the past, then you should have to change nothing in your configuration. My guess is that your ProxyPass directives for the :80 VirtualHost were somehow damaged in the switch-over. Can you show us the :443 configuration versus the :80 configuration in terms of ProxyPass and ProxyPassReverse directives? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9 FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1 zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/ RpQ2KXVnBjLHYdoFGpSD =YmrV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Brand new to Tomcat
On Tue, Jun 16, 2015 at 4:06 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Larry,
On 6/16/15 3:34 PM, Cohen, Laurence wrote:
On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
Larry,
BTW, you're doing great. Thanks for battling-through. See below.
On 6/16/15 2:29 PM, Cohen, Laurence wrote:
*** nss.conf.testweb01 ***
Listen 443
AddType application/x-x509-ca-cert .crt AddType
application/x-pkcs7-crl.crl
NSSPassPhraseDialog file:/etc/httpd/.password.conf
#NSSPassPhraseDialog builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 1 NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
VirtualHost _default_:443
DocumentRoot /var/www/docroot NSSProxyCheckPeerCN Off
NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off
NSSRenegotiation on NSSRequireSafeNegotiation on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
sa_aes_256_sha
NSSProxyCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
sa_aes_256_sha
NSSProtocol TLSv1 NSSNickname Server-Cert
NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP
off
ProxyPreserveHost On
Location /dse-help #SSLRenegBufferSize 10486000
NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help
ProxyPassReverse https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help /Location
Okay, good: here's the real meat of the file (repeated over and
over, of course). The Location matches an incoming URL and then
the stuff between the Location and /Location will be effective
for requests whose URLs match that pattern.
So, for a request for /dse-help, the request is forwarded-over to
Tomcat on port 8007 using the https:// protocol. The
ProxyPassReverse will re-write response headers like Location and
Set-Cookie to make sure they point to the reverse proxy (httpd)
server instead of Tomcat (testapp01:8007).
This is all you need to get things working. Since the above is
from the :443 VirtualHost, you just need to make sure that similar
configuration exists in the :80 VirtualHost configuration files.
# initialize the SSL headers to a blank value to avoid http
header forgeries RequestHeader set SSL_CLIENT_CERT
RequestHeader set SSL_CIPHER RequestHeader set
SSL_SESSION_ID RequestHeader set SSL_CIPHER_USEKEYSIZE
I'm not entirely sure:
a) How mod_nss expects to send the original HTTPS information to
Tomcat b) Whether or not Tomcat is configured to detect this
information and make sure it's available to the container/web
application c) In what order the StdEnvVars and RequestHeader
set operations take place.
I would want to make sure you've got all that right so tht the
following takes place:
1. Request comes in 2. Request has HTTPS-related headers stripped
3. Request has HTTPS-related headers added during proxying
You might consider using RequestHeader unset instead of
RequestHeader set ''. There's no reason to send-over a blank
string.
RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}s
RequestHeader set SSL_CIPHER %{SSL_CIPHER}s RequestHeader
set SSL_SESSION_ID %{SSL_SESSION_ID}s RequestHeader set
SSL_CIPHER_USEKEYSIZE %{SSL_CIPHER_USEKEYSIZE}s
If you are going to be setting each of these with new values,
you may as well not bother to unset (or set them to )
beforehand. I think it's just extra processing that wastes time and
doesn't accomplish. Of course, you'll want to verify that I'm
correct in that it doesn't matter if you remove the unsets before
the sets, but I think you'll be okay.
*** rewwrite.conf.testweb01 ***
# # rewrite.conf: # These rules handle all http:// protocol
requests. # RewriteEngine on
# General: # Disable HTTP TRACE on all requests. RewriteCond
%{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
# General: # Redirect requests to https, EXCEPT for the
favicon, User-Defined URLs, System-Defined URLs, DDMS, AOP. #
https rewrite rules are found in ssl.conf. RewriteCond
%{SERVER_PROTOCOL} !https RewriteCond %{REQUEST_URI}
!^/favicon.ico RewriteCond %{REQUEST_URI} !^/mdr/ns
RewriteCond %{REQUEST_URI} !^/mdr/irs RewriteCond
%{REQUEST_URI} !^/mdr/documents RewriteCond
%{REQUEST_URI} !^/dse/uriService RewriteCond
%{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
Re: Brand new to Tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Larry,
On 6/16/15 3:34 PM, Cohen, Laurence wrote:
On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
Larry,
BTW, you're doing great. Thanks for battling-through. See below.
On 6/16/15 2:29 PM, Cohen, Laurence wrote:
*** nss.conf.testweb01 ***
Listen 443
AddType application/x-x509-ca-cert .crt AddType
application/x-pkcs7-crl.crl
NSSPassPhraseDialog file:/etc/httpd/.password.conf
#NSSPassPhraseDialog builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 1 NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
VirtualHost _default_:443
DocumentRoot /var/www/docroot NSSProxyCheckPeerCN Off
NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off
NSSRenegotiation on NSSRequireSafeNegotiation on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
sa_aes_256_sha
NSSProxyCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
sa_aes_256_sha
NSSProtocol TLSv1 NSSNickname Server-Cert
NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP
off
ProxyPreserveHost On
Location /dse-help #SSLRenegBufferSize 10486000
NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help
ProxyPassReverse https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help /Location
Okay, good: here's the real meat of the file (repeated over and
over, of course). The Location matches an incoming URL and then
the stuff between the Location and /Location will be effective
for requests whose URLs match that pattern.
So, for a request for /dse-help, the request is forwarded-over to
Tomcat on port 8007 using the https:// protocol. The
ProxyPassReverse will re-write response headers like Location and
Set-Cookie to make sure they point to the reverse proxy (httpd)
server instead of Tomcat (testapp01:8007).
This is all you need to get things working. Since the above is
from the :443 VirtualHost, you just need to make sure that similar
configuration exists in the :80 VirtualHost configuration files.
# initialize the SSL headers to a blank value to avoid http
header forgeries RequestHeader set SSL_CLIENT_CERT
RequestHeader set SSL_CIPHER RequestHeader set
SSL_SESSION_ID RequestHeader set SSL_CIPHER_USEKEYSIZE
I'm not entirely sure:
a) How mod_nss expects to send the original HTTPS information to
Tomcat b) Whether or not Tomcat is configured to detect this
information and make sure it's available to the container/web
application c) In what order the StdEnvVars and RequestHeader
set operations take place.
I would want to make sure you've got all that right so tht the
following takes place:
1. Request comes in 2. Request has HTTPS-related headers stripped
3. Request has HTTPS-related headers added during proxying
You might consider using RequestHeader unset instead of
RequestHeader set ''. There's no reason to send-over a blank
string.
RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}s
RequestHeader set SSL_CIPHER %{SSL_CIPHER}s RequestHeader
set SSL_SESSION_ID %{SSL_SESSION_ID}s RequestHeader set
SSL_CIPHER_USEKEYSIZE %{SSL_CIPHER_USEKEYSIZE}s
If you are going to be setting each of these with new values,
you may as well not bother to unset (or set them to )
beforehand. I think it's just extra processing that wastes time and
doesn't accomplish. Of course, you'll want to verify that I'm
correct in that it doesn't matter if you remove the unsets before
the sets, but I think you'll be okay.
*** rewwrite.conf.testweb01 ***
# # rewrite.conf: # These rules handle all http:// protocol
requests. # RewriteEngine on
# General: # Disable HTTP TRACE on all requests. RewriteCond
%{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
# General: # Redirect requests to https, EXCEPT for the
favicon, User-Defined URLs, System-Defined URLs, DDMS, AOP. #
https rewrite rules are found in ssl.conf. RewriteCond
%{SERVER_PROTOCOL} !https RewriteCond %{REQUEST_URI}
!^/favicon.ico RewriteCond %{REQUEST_URI} !^/mdr/ns
RewriteCond %{REQUEST_URI} !^/mdr/irs RewriteCond
%{REQUEST_URI} !^/mdr/documents RewriteCond
%{REQUEST_URI} !^/dse/uriService RewriteCond
%{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
!^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
RewriteCond %{REQUEST_URI} !^/dse/downloads
# query string containing wsdl (e.g.
somepath/publish?wsdl), let it
Re: Brand new to Tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Larry,
BTW, you're doing great. Thanks for battling-through. See below.
On 6/16/15 2:29 PM, Cohen, Laurence wrote:
*** nss.conf.testweb01 ***
Listen 443
AddType application/x-x509-ca-cert .crt AddType
application/x-pkcs7-crl.crl
NSSPassPhraseDialog file:/etc/httpd/.password.conf
#NSSPassPhraseDialog builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 1 NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
VirtualHost _default_:443
DocumentRoot /var/www/docroot NSSProxyCheckPeerCN Off NSSEngine
on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on
NSSRequireSafeNegotiation on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
NSSProxyCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase
/etc/httpd/alias NSSFIPS on NSSOCSP off
ProxyPreserveHost On
Location /dse-help #SSLRenegBufferSize 10486000 NSSVerifyClient
none NSSOptions +StdEnvVars ProxyPass
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help ProxyPassReverse
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help /Location
Okay, good: here's the real meat of the file (repeated over and over,
of course). The Location matches an incoming URL and then the stuff
between the Location and /Location will be effective for requests
whose URLs match that pattern.
So, for a request for /dse-help, the request is forwarded-over to
Tomcat on port 8007 using the https:// protocol. The ProxyPassReverse
will re-write response headers like Location and Set-Cookie to make
sure they point to the reverse proxy (httpd) server instead of Tomcat
(testapp01:8007).
This is all you need to get things working. Since the above is from
the :443 VirtualHost, you just need to make sure that similar
configuration exists in the :80 VirtualHost configuration files.
# initialize the SSL headers to a blank value to avoid http header
forgeries RequestHeader set SSL_CLIENT_CERT RequestHeader set
SSL_CIPHER RequestHeader set SSL_SESSION_ID RequestHeader set
SSL_CIPHER_USEKEYSIZE
I'm not entirely sure:
a) How mod_nss expects to send the original HTTPS information to Tomcat
b) Whether or not Tomcat is configured to detect this information and
make sure it's available to the container/web application
c) In what order the StdEnvVars and RequestHeader set operations
take place.
I would want to make sure you've got all that right so tht the
following takes place:
1. Request comes in
2. Request has HTTPS-related headers stripped
3. Request has HTTPS-related headers added during proxying
You might consider using RequestHeader unset instead of
RequestHeader set ''. There's no reason to send-over a blank string.
RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}s
RequestHeader set SSL_CIPHER %{SSL_CIPHER}s RequestHeader set
SSL_SESSION_ID %{SSL_SESSION_ID}s RequestHeader set
SSL_CIPHER_USEKEYSIZE %{SSL_CIPHER_USEKEYSIZE}s
If you are going to be setting each of these with new values, you
may as well not bother to unset (or set them to ) beforehand. I
think it's just extra processing that wastes time and doesn't
accomplish. Of course, you'll want to verify that I'm correct in that
it doesn't matter if you remove the unsets before the sets, but I
think you'll be okay.
*** rewwrite.conf.testweb01 ***
# # rewrite.conf: # These rules handle all http:// protocol
requests. # RewriteEngine on
# General: # Disable HTTP TRACE on all requests. RewriteCond
%{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
# General: # Redirect requests to https, EXCEPT for the favicon,
User-Defined URLs, System-Defined URLs, DDMS, AOP. # https rewrite
rules are found in ssl.conf. RewriteCond %{SERVER_PROTOCOL}
!https RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond
%{REQUEST_URI} !^/mdr/ns RewriteCond %{REQUEST_URI}
!^/mdr/irs RewriteCond %{REQUEST_URI} !^/mdr/documents
RewriteCond %{REQUEST_URI} !^/dse/uriService RewriteCond
%{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
!^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
RewriteCond %{REQUEST_URI} !^/dse/downloads
# query string containing wsdl (e.g. somepath/publish?wsdl), let
it fetch as http RewriteCond %{QUERY_STRING} !wsdl
RewriteRule ^/(.*)$ https://testweb01/$1
https://testweb01.novetta.com/$1 [last,redirect]
Oh, man. This is awful.
I'll bet the SSL-based
Re: Brand new to Tomcat
On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Larry,
BTW, you're doing great. Thanks for battling-through. See below.
On 6/16/15 2:29 PM, Cohen, Laurence wrote:
*** nss.conf.testweb01 ***
Listen 443
AddType application/x-x509-ca-cert .crt AddType
application/x-pkcs7-crl.crl
NSSPassPhraseDialog file:/etc/httpd/.password.conf
#NSSPassPhraseDialog builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 1 NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
VirtualHost _default_:443
DocumentRoot /var/www/docroot NSSProxyCheckPeerCN Off NSSEngine
on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on
NSSRequireSafeNegotiation on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
NSSProxyCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase
/etc/httpd/alias NSSFIPS on NSSOCSP off
ProxyPreserveHost On
Location /dse-help #SSLRenegBufferSize 10486000 NSSVerifyClient
none NSSOptions +StdEnvVars ProxyPass
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help ProxyPassReverse
https://testapp01:8007/dse-help
https://testapp01.novetta.com:8007/dse-help /Location
Okay, good: here's the real meat of the file (repeated over and over,
of course). The Location matches an incoming URL and then the stuff
between the Location and /Location will be effective for requests
whose URLs match that pattern.
So, for a request for /dse-help, the request is forwarded-over to
Tomcat on port 8007 using the https:// protocol. The ProxyPassReverse
will re-write response headers like Location and Set-Cookie to make
sure they point to the reverse proxy (httpd) server instead of Tomcat
(testapp01:8007).
This is all you need to get things working. Since the above is from
the :443 VirtualHost, you just need to make sure that similar
configuration exists in the :80 VirtualHost configuration files.
# initialize the SSL headers to a blank value to avoid http header
forgeries RequestHeader set SSL_CLIENT_CERT RequestHeader set
SSL_CIPHER RequestHeader set SSL_SESSION_ID RequestHeader set
SSL_CIPHER_USEKEYSIZE
I'm not entirely sure:
a) How mod_nss expects to send the original HTTPS information to Tomcat
b) Whether or not Tomcat is configured to detect this information and
make sure it's available to the container/web application
c) In what order the StdEnvVars and RequestHeader set operations
take place.
I would want to make sure you've got all that right so tht the
following takes place:
1. Request comes in
2. Request has HTTPS-related headers stripped
3. Request has HTTPS-related headers added during proxying
You might consider using RequestHeader unset instead of
RequestHeader set ''. There's no reason to send-over a blank string.
RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}s
RequestHeader set SSL_CIPHER %{SSL_CIPHER}s RequestHeader set
SSL_SESSION_ID %{SSL_SESSION_ID}s RequestHeader set
SSL_CIPHER_USEKEYSIZE %{SSL_CIPHER_USEKEYSIZE}s
If you are going to be setting each of these with new values, you
may as well not bother to unset (or set them to ) beforehand. I
think it's just extra processing that wastes time and doesn't
accomplish. Of course, you'll want to verify that I'm correct in that
it doesn't matter if you remove the unsets before the sets, but I
think you'll be okay.
*** rewwrite.conf.testweb01 ***
# # rewrite.conf: # These rules handle all http:// protocol
requests. # RewriteEngine on
# General: # Disable HTTP TRACE on all requests. RewriteCond
%{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
# General: # Redirect requests to https, EXCEPT for the favicon,
User-Defined URLs, System-Defined URLs, DDMS, AOP. # https rewrite
rules are found in ssl.conf. RewriteCond %{SERVER_PROTOCOL}
!https RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond
%{REQUEST_URI} !^/mdr/ns RewriteCond %{REQUEST_URI}
!^/mdr/irs RewriteCond %{REQUEST_URI} !^/mdr/documents
RewriteCond %{REQUEST_URI} !^/dse/uriService RewriteCond
%{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
!^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
RewriteCond %{REQUEST_URI} !^/dse/downloads
# query string containing wsdl (e.g. somepath/publish?wsdl), let
it fetch as http RewriteCond %{QUERY_STRING}
Session init problem since moving to new server/tomcat
Recently we moved our application from an old ubuntu to a newer centos box. We upgraded our JAVA version, tomcat (from v5 to latest v6) and basically all server components. Local tests of our application showed no problems with these newer versions, in fact it has been developed with these since quite some time. But now we seem to have a problem with our session management/creation, however only on the new live server, not locally. Whenever a user visits a page (the login page) for the very first time (no JSESSIONID-Cookie), the first login form submit does not work. Our live application obviously encounters some kind of unexpected stuff. The followup form submit works as expected. The JSESSIONID is created on the first page load btw. The person who wrote this part of our application has gone AWOL and locally we cannot reproduce this. Do you guys have any idea what could be responsible for this? I obviously copied all the tomcat settings from the older version and I cannot find anything worthy in the logs. Thanks, Martin http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch und sozial denkende Menschen! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session init problem since moving to new server/tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 11/8/13, 9:59 AM, Martin wrote: Recently we moved our application from an old ubuntu to a newer centos box. We upgraded our JAVA version, tomcat (from v5 to latest v6) and basically all server components. I would highly recommend that you upgrade directly to 7.0.x... moving from Tomcat 6 to Tomcat 7 is much easier than the transition from 5.0 to 6.0. Make the investment, now. Tomcat 8 is just around the corner which means that Tomcat 6's days are numbered (though it may still have 1000 days left in its lifetime). Local tests of our application showed no problems with these newer versions, in fact it has been developed with these since quite some time. But now we seem to have a problem with our session management/creation, however only on the new live server, not locally. Whenever a user visits a page (the login page) for the very first time (no JSESSIONID-Cookie), the first login form submit does not work. Our live application obviously encounters some kind of unexpected stuff. The followup form submit works as expected. The JSESSIONID is created on the first page load btw. What does your login form look like? Often, users forget to encode the session id in the URL for the form like this: form action=j_security_check It would be better to do this: form action=%= response.encoreURL(request.getContextPath() + /j_security_check)) % / That way, Tomcat will get the session identifier whether cookies are in use or not. The person who wrote this part of our application has gone AWOL and locally we cannot reproduce this. Do you guys have any idea what could be responsible for this? I obviously copied all the tomcat settings from the older version and I cannot find anything worthy in the logs. Some things have changed from Tomcat 5 to Tomcat 6 and later, especially with session-handling during login. For example, Tomcat now switches session-ids after a successful login in order to protect against session-fixation attacks. Also, Tomcat now requires (though I'm not sure if this is different from the Tomcat 5 days) a session to be in place in order to show the login screen because it needs to store the original request somewhere for a post-authentication redirect. Are you using the standard spec-defined login process: 1. User requests a protected page 2. Container challenges user for credentials 3. User provides valid credentials 4. Container sends the user to the originally-requested resource ? Or, are you using what I call a drive-by login where you just have the login page showing in index.jsp or whatever with a login button? This last one won't work the way you expect it to work, because the spec (stupidly, IMO) didn't include a standard way for containers to handle unsolicited logins. These days (Servlet 3.0, which means Tomcat 7 and later), you can write your own login-handler for these drive-by logins. (Actually, looking at the documentation for HttpServletRequest.login, it seems like this might not actually work (or if it does, it might violate the spec) since it says that getAuthType must return null in order for login() to be successful. That sounds to me like either the container is in total control, or the webapp is in total control. Hmm.) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSfQHIAAoJEBzwKT+lPKRY9OcQAMMMAIpVuFtUhwWv9sTbs0uK fnDB/VXVytAsYcbu4rVrgqiculcGP/2CkhZI2nle43FoPNZkMMbnJAr2AczYdV69 MTEoBOeY5rPQiUKs89KCKUN6V0kQkkv+cBQOaMzbGDBYd7vMgpONh9LXKuZjMkKC iBpWdTRz1H79+82VpfGO7obVp+k3QXS4hLI/rMT3o01vacfQXJc6C0+vvmlFLTGH QCyU0NfRbeT2MPGBmCUabjLpf7S/kRv2d1l26Az6AYOZHm/s/Ee9+yyZ+MuXOsJk wEOX7/+jDcshQd1R+tiQdEyFJGCqKOgGbRJ5AwVRXyWXjgEUXj3YzXAmK7NrBF39 bu8WQib8y8kOiIo7ME1YF+qNs6eXDqdeEyf9l2zh19L0P7jn43Y3vWvOaqI34kML 9BBsh32f6KD5BpW3fQ9WgG8Ssk+9TK/w6AkQvG7RYhSzuiQykJslvuYNrWCFR+Nf r8rDbqnLrcWPJ5RT19vyitJHIvNEIm3RKA/+bEfVQwBFMS4FEgiOqknEUU8m8VZD 1SxB8eXR2wfOA9H4BsSh7fmTFCneDZv8+h2Hntuf9IKe9fB4G8lU1RThH2gXl8rB tOSix5WKKadvuss42tpKtsOI2IaSObcK163pdZIc0QUHOFMZC/15wimRlGrW0vbL bF36rsMYpfhFG8naSZq5 =mhI6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session init problem since moving to new server/tomcat
Thank you Christopher for your in depth annotations. We just downgraded from v6.0.34 to .20 and the problem has vanished. We obviously have some changes to do before we can upgrade to v7 as far as the session handling is concerned. Your post will help us along the way. Thanks again. Martin Am 2013-11-08 16:22, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 11/8/13, 9:59 AM, Martin wrote: Recently we moved our application from an old ubuntu to a newer centos box. We upgraded our JAVA version, tomcat (from v5 to latest v6) and basically all server components. I would highly recommend that you upgrade directly to 7.0.x... moving from Tomcat 6 to Tomcat 7 is much easier than the transition from 5.0 to 6.0. Make the investment, now. Tomcat 8 is just around the corner which means that Tomcat 6's days are numbered (though it may still have 1000 days left in its lifetime). Local tests of our application showed no problems with these newer versions, in fact it has been developed with these since quite some time. But now we seem to have a problem with our session management/creation, however only on the new live server, not locally. Whenever a user visits a page (the login page) for the very first time (no JSESSIONID-Cookie), the first login form submit does not work. Our live application obviously encounters some kind of unexpected stuff. The followup form submit works as expected. The JSESSIONID is created on the first page load btw. What does your login form look like? Often, users forget to encode the session id in the URL for the form like this: form action=j_security_check It would be better to do this: form action=%= response.encoreURL(request.getContextPath() + /j_security_check)) % / That way, Tomcat will get the session identifier whether cookies are in use or not. The person who wrote this part of our application has gone AWOL and locally we cannot reproduce this. Do you guys have any idea what could be responsible for this? I obviously copied all the tomcat settings from the older version and I cannot find anything worthy in the logs. Some things have changed from Tomcat 5 to Tomcat 6 and later, especially with session-handling during login. For example, Tomcat now switches session-ids after a successful login in order to protect against session-fixation attacks. Also, Tomcat now requires (though I'm not sure if this is different from the Tomcat 5 days) a session to be in place in order to show the login screen because it needs to store the original request somewhere for a post-authentication redirect. Are you using the standard spec-defined login process: 1. User requests a protected page 2. Container challenges user for credentials 3. User provides valid credentials 4. Container sends the user to the originally-requested resource ? Or, are you using what I call a drive-by login where you just have the login page showing in index.jsp or whatever with a login button? This last one won't work the way you expect it to work, because the spec (stupidly, IMO) didn't include a standard way for containers to handle unsolicited logins. These days (Servlet 3.0, which means Tomcat 7 and later), you can write your own login-handler for these drive-by logins. (Actually, looking at the documentation for HttpServletRequest.login, it seems like this might not actually work (or if it does, it might violate the spec) since it says that getAuthType must return null in order for login() to be successful. That sounds to me like either the container is in total control, or the webapp is in total control. Hmm.) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSfQHIAAoJEBzwKT+lPKRY9OcQAMMMAIpVuFtUhwWv9sTbs0uK fnDB/VXVytAsYcbu4rVrgqiculcGP/2CkhZI2nle43FoPNZkMMbnJAr2AczYdV69 MTEoBOeY5rPQiUKs89KCKUN6V0kQkkv+cBQOaMzbGDBYd7vMgpONh9LXKuZjMkKC iBpWdTRz1H79+82VpfGO7obVp+k3QXS4hLI/rMT3o01vacfQXJc6C0+vvmlFLTGH QCyU0NfRbeT2MPGBmCUabjLpf7S/kRv2d1l26Az6AYOZHm/s/Ee9+yyZ+MuXOsJk wEOX7/+jDcshQd1R+tiQdEyFJGCqKOgGbRJ5AwVRXyWXjgEUXj3YzXAmK7NrBF39 bu8WQib8y8kOiIo7ME1YF+qNs6eXDqdeEyf9l2zh19L0P7jn43Y3vWvOaqI34kML 9BBsh32f6KD5BpW3fQ9WgG8Ssk+9TK/w6AkQvG7RYhSzuiQykJslvuYNrWCFR+Nf r8rDbqnLrcWPJ5RT19vyitJHIvNEIm3RKA/+bEfVQwBFMS4FEgiOqknEUU8m8VZD 1SxB8eXR2wfOA9H4BsSh7fmTFCneDZv8+h2Hntuf9IKe9fB4G8lU1RThH2gXl8rB tOSix5WKKadvuss42tpKtsOI2IaSObcK163pdZIc0QUHOFMZC/15wimRlGrW0vbL bF36rsMYpfhFG8naSZq5 =mhI6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch und sozial denkende Menschen! - To unsubscribe, e-mail:
Re: Session init problem since moving to new server/tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 11/8/13, 11:40 AM, Martin wrote: Thank you Christopher for your in depth annotations. We just downgraded from v6.0.34 to .20 and the problem has vanished. We obviously have some changes to do before we can upgrade to v7 as far as the session handling is concerned. Your post will help us along the way. Thanks again. I really suspect the session id switching is the problem. Check the changelog between .20 and .34 for things that smell like they might be related to your issue. You should really re-upgrade back to 6.0.latest as soon as you can: there are good performance and important security updates included in those later versions. - -chris Am 2013-11-08 16:22, schrieb Christopher Schultz: Martin, On 11/8/13, 9:59 AM, Martin wrote: Recently we moved our application from an old ubuntu to a newer centos box. We upgraded our JAVA version, tomcat (from v5 to latest v6) and basically all server components. I would highly recommend that you upgrade directly to 7.0.x... moving from Tomcat 6 to Tomcat 7 is much easier than the transition from 5.0 to 6.0. Make the investment, now. Tomcat 8 is just around the corner which means that Tomcat 6's days are numbered (though it may still have 1000 days left in its lifetime). Local tests of our application showed no problems with these newer versions, in fact it has been developed with these since quite some time. But now we seem to have a problem with our session management/creation, however only on the new live server, not locally. Whenever a user visits a page (the login page) for the very first time (no JSESSIONID-Cookie), the first login form submit does not work. Our live application obviously encounters some kind of unexpected stuff. The followup form submit works as expected. The JSESSIONID is created on the first page load btw. What does your login form look like? Often, users forget to encode the session id in the URL for the form like this: form action=j_security_check It would be better to do this: form action=%= response.encoreURL(request.getContextPath() + /j_security_check)) % / That way, Tomcat will get the session identifier whether cookies are in use or not. The person who wrote this part of our application has gone AWOL and locally we cannot reproduce this. Do you guys have any idea what could be responsible for this? I obviously copied all the tomcat settings from the older version and I cannot find anything worthy in the logs. Some things have changed from Tomcat 5 to Tomcat 6 and later, especially with session-handling during login. For example, Tomcat now switches session-ids after a successful login in order to protect against session-fixation attacks. Also, Tomcat now requires (though I'm not sure if this is different from the Tomcat 5 days) a session to be in place in order to show the login screen because it needs to store the original request somewhere for a post-authentication redirect. Are you using the standard spec-defined login process: 1. User requests a protected page 2. Container challenges user for credentials 3. User provides valid credentials 4. Container sends the user to the originally-requested resource ? Or, are you using what I call a drive-by login where you just have the login page showing in index.jsp or whatever with a login button? This last one won't work the way you expect it to work, because the spec (stupidly, IMO) didn't include a standard way for containers to handle unsolicited logins. These days (Servlet 3.0, which means Tomcat 7 and later), you can write your own login-handler for these drive-by logins. (Actually, looking at the documentation for HttpServletRequest.login, it seems like this might not actually work (or if it does, it might violate the spec) since it says that getAuthType must return null in order for login() to be successful. That sounds to me like either the container is in total control, or the webapp is in total control. Hmm.) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch und sozial denkende Menschen! - 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.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSfVLaAAoJEBzwKT+lPKRYK7UP/0MUSJJvTiYnJ1RjzehRGSmG oky4yx6kHcFJ/eJnl3MwdvZpmiI2+AZ6i9cwcHy9YkLMAwbegdnYMPAnmqMQrqDa YybfcA877nbseqDrQnRDq2CM4E6KZU9zHypimuswBImHUF9dsqVrdotFx0iLI39y
Re: New to tomcat and jsp
The installation is pretty straightforward. It used to be a pain in the neck to set up, but now they made it easier to get up and running. Check out http://jakarta.apache.org/tomcat/ and for installation: http://jakarta.apache.org/tomcat/tom...doc/setup.html These are two good places to get started with JSP http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ and http://www.jsptut.com/ Stuart Johnson http://www.clickss.com http://www.clickss.comClickSSL.com | geotrust quickssl premium, true business ssl, geo trust ssl -- View this message in context: http://old.nabble.com/New-to-tomcat-and-jsp-tp27510419p27527086.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
New to tomcat and jsp
I am trying to learn JSP. So tried to install Tomcat 6. Downloaded the compressd file and extracted them. I went into the bin directory and double clicked the startup batch file. When I do that I see the command prompt for a split of a second and then it just vanishes. I was told that the command prompt window should remain open. What am I doing wrong? -- View this message in context: http://old.nabble.com/New-to-tomcat-and-jsp-tp27510419p27510419.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: New to tomcat and jsp
1. Have you installed JDK? 2. Check if you have set JAVA_HOME 3. Run the startup.bat from a command window and see what error it outputs -Original Message- From: rajugurung [mailto:rajugur...@hotmail.com] Sent: Monday, February 08, 2010 8:49 PM To: users@tomcat.apache.org Subject: New to tomcat and jsp I am trying to learn JSP. So tried to install Tomcat 6. Downloaded the compressd file and extracted them. I went into the bin directory and double clicked the startup batch file. When I do that I see the command prompt for a split of a second and then it just vanishes. I was told that the command prompt window should remain open. What am I doing wrong? -- View this message in context: http://old.nabble.com/New-to-tomcat-and-jsp-tp27510419p27510419.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to tomcat and jsp
Thank you all.. I figured it out. I had to set the enviornment variable JAVA_HOME. rajugurung wrote: I am trying to learn JSP. So tried to install Tomcat 6. Downloaded the compressd file and extracted them. I went into the bin directory and double clicked the startup batch file. When I do that I see the command prompt for a split of a second and then it just vanishes. I was told that the command prompt window should remain open. What am I doing wrong? -- View this message in context: http://old.nabble.com/New-to-tomcat-and-jsp-tp27510419p27510688.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 12/12/2009 1:40 PM, Caldarale, Charles R wrote: From: Adria Stembridge [mailto:adrya.stembri...@gmail.com] Subject: Re: New to Tomcat -- SSL I compiled jsvc per tomcat 5.5 documentation. [Linux] service tomcat5 stop [Linux] ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar -outfile ./logs/catalina.out -errfile ./logs/catalina.err org.apache.catalina.startup.Bootstrap Looks like you didn't start jsvc under the root userid. I'm not sure what the recommended technique is for using jsvc, but making javc setuid=root seems like a reasonable thing to do: this allows a non-root user to start Tomcat, but does not give that user any further privileges. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksmcDUACgkQ9CaO5/Lv0PCG3wCfRuKvg/gpOGunLFZTBIVNw6PU cGQAn0azpL/NnHiL+FmJoaZIPCeQdvWt =D/Jl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
Don't the Tomcat logs say anything helpful ? Actually, yes... SEVERE: Catalina.start: LifecycleException: service.getName(): Catalina; Protocol handler start failed: java.net.BindException: *Permission denied:80* at org.apache.catalina.connector.Connector.start(Connector.java:1097) at org.apache.catalina.core.StandardService.start(StandardService.java:457) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Dec 11, 2009 5:21:20 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 643 ms I'm approaching my wits end with this project. *server.xml*: ?xml version=1.0 encoding=UTF-8? Server Listener className=org.apache.catalina.core.AprLifecycleListener/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener/ Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ Listener className=org.apache.catalina.mbeans.ServerLifecycleListener/ GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Resource auth=Container description=User database that can be updated and saved name=UserDatabase type=org.apache.catalina.UserDatabase pathname=conf/tomcat-users.xml factory=org.apache.catalina.users.MemoryUserDatabaseFactory/ /GlobalNamingResources Service name=Catalina Connector port=80 redirectPort=443 minSpareThreads=25 connectionTimeout=2 maxSpareThreads=75 maxThreads=150 /Connector Connector port=443 scheme=https secure=true keystoreFile=/my/keystore keystorePass=mysecretpassword SSLEnabled=true sslProtocol=TLS maxSpareThreads=75 maxThreads=150 minSpareThreads=25 clientAuth=false /Connector Engine defaultHost=localhost name=Catalina Realm className=org.apache.catalina.realm.UserDatabaseRealm/ Host appBase=webapps name=localhost /Host /Engine /Service /Server *Scanning ports from a different system:* [Linux]:~$ nmap -p80,443,8080,8443 my.domain.org Starting Nmap 4.62 ( http://nmap.org ) at 2009-12-12 12:15 EST Interesting ports on my.domain.org (1.1.1.1): PORT STATE SERVICE 80/tcp open http 443/tcp open https 8080/tcp closed http-proxy 8443/tcp closed https-alt Nmap done: 1 IP address (1 host up) scanned in 0.071 seconds *Iptables -L* Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhereicmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhereudp dpt:ipp ACCEPT tcp -- anywhere anywheretcp dpt:ipp ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:https ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:http ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:webcache ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:pcsync-https ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:ddi-tcp-1 REJECT all -- anywhere anywherereject-with icmp-host-prohibited *netstat -tln * Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:33060.0.0.0:* LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:25
RE: New to Tomcat -- SSL
From: Adria Stembridge [mailto:adrya.stembri...@gmail.com] Subject: Re: New to Tomcat -- SSL SEVERE: Catalina.start: LifecycleException: service.getName(): Catalina; Protocol handler start failed: java.net.BindException: *Permission denied:80* at org.apache.catalina.connector.Connector.start(Connector.java:1097) Linux/UNIX systems do not allow unprivileged userids to access ports 1024. Although you can run Tomcat under the root userid, this is not recommended for security reasons. Instead, start Tomcat with jsvc: http://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix%20daemon - 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: New to Tomcat -- SSL
Linux/UNIX systems do not allow unprivileged userids to access ports 1024. Although you can run Tomcat under the root userid, this is not recommended for security reasons. Instead, start Tomcat with jsvc: http://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix%20daemon - Chuck I compiled jsvc per tomcat 5.5 documentation. [Linux] service tomcat5 stop [Linux] ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar -outfile ./logs/catalina.out -errfile ./logs/catalina.err org.apache.catalina.startup.Bootstrap No errors at the prompt. Checking catalina.out logfile: Dec 12, 2009 1:25:50 PM org.apache.coyote.http11.Http11BaseProtocol start SEVERE: Error starting endpoint java.net.BindException: Permission denied:80 at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:298) at org.apache.tomcat.util.net.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoint.java:313) at org.apache.coyote.http11.Http11BaseProtocol.start(Http11BaseProtocol.java:151) at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:76) at org.apache.catalina.connector.Connector.start(Connector.java:1090) at org.apache.catalina.core.StandardService.start(StandardService.java:457) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177) Dec 12, 2009 1:25:50 PM org.apache.catalina.startup.Catalina start SEVERE: Catalina.start: LifecycleException: service.getName(): Catalina; Protocol handler start failed: java.net.BindException: Per mission denied:80 at org.apache.catalina.connector.Connector.start(Connector.java:1097) at org.apache.catalina.core.StandardService.start(StandardService.java:457) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177) Dec 12, 2009 1:25:50 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 641 ms
Re: New to Tomcat -- SSL
I've been at this for two days. Learning a lot, but this is production and needs to get back to service. Is there another way, other than revoking/requesting a new SSL certificate and using apache mod_jk? Tomcat works under 8080 and 8443 currently. Isn't there a way to forward 8443 to 443 with iptables?
RE: New to Tomcat -- SSL
From: Adria Stembridge [mailto:adrya.stembri...@gmail.com] Subject: Re: New to Tomcat -- SSL Tomcat works under 8080 and 8443 currently. Isn't there a way to forward 8443 to 443 with iptables? Yes, that's frequently done. From the Tomcat FAQ: - Another way is to use Iptables to redirect Port 80 and 443 to user ports (1024) * /sbin/iptables -A FORWARD -p tcp --destination-port 443 -j ACCEPT * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 443 --to-ports 8443 * /sbin/iptables -A FORWARD -p tcp --destination-port 80 -j ACCEPT * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 80 --to-ports 8080 /sbin/iptables-save or /etc/init.d/iptables save Consult the iptables man pages for details. - 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: New to Tomcat -- SSL
From: Adria Stembridge [mailto:adrya.stembri...@gmail.com] Subject: Re: New to Tomcat -- SSL I compiled jsvc per tomcat 5.5 documentation. [Linux] service tomcat5 stop [Linux] ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar -outfile ./logs/catalina.out -errfile ./logs/catalina.err org.apache.catalina.startup.Bootstrap Looks like you didn't start jsvc under the root userid. Also note this from the instructions: jsvc has other useful parameters, such as -user which causes it to switch to another user after the daemon initialization is complete. This allows, for example, running Tomcat as a non privileged user while still being able to use privileged ports. - 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: New to Tomcat -- SSL
Success. iptables -save iptables-save weren't saving the changes. Issuing *service itptables save* did the trick.Tomcat is now running over ports 80 443. Thanks for everyone's assistance. a On Sat, Dec 12, 2009 at 1:36 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Adria Stembridge [mailto:adrya.stembri...@gmail.com] Subject: Re: New to Tomcat -- SSL Tomcat works under 8080 and 8443 currently. Isn't there a way to forward 8443 to 443 with iptables? Yes, that's frequently done. From the Tomcat FAQ: - Another way is to use Iptables to redirect Port 80 and 443 to user ports (1024) * /sbin/iptables -A FORWARD -p tcp --destination-port 443 -j ACCEPT * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 443 --to-ports 8443 * /sbin/iptables -A FORWARD -p tcp --destination-port 80 -j ACCEPT * /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 80 --to-ports 8080 /sbin/iptables-save or /etc/init.d/iptables save Consult the iptables man pages for details. - 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: New to Tomcat -- SSL
Adria Stembridge wrote: I'm setting up a standalone instance of Tomcat with SSL. Tomcat5 is installed on the RHEL5 box and the sample pages load fine. I created a csr using keytool and requested a certificate from Verisign. After this is imported (I'm waiting on delivery from verisign), how would I configure Tomcat to route traffic from http://domain.com:8443 to https://domain.com? Thank you. Set the port attribute on the SSL connector to 443. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
On 11/12/2009 11:47, Adria Stembridge wrote: I'm setting up a standalone instance of Tomcat with SSL. Tomcat5 is installed on the RHEL5 box and the sample pages load fine. I created a csr using keytool and requested a certificate from Verisign. After this is imported (I'm waiting on delivery from verisign), how would I configure Tomcat to route traffic from http://domain.com:8443 to https://domain.com? Thank you. Tomcat 5.5 or Tomcat 5.0? The latter is no longer supported. Change the port of the Connector from 8443 to 443, assuming you have root rights (required to configure a port below 1024). p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adria, On 12/11/2009 6:47 AM, Adria Stembridge wrote: I'm setting up a standalone instance of Tomcat with SSL. Tomcat5 is installed on the RHEL5 box and the sample pages load fine. I created a csr using keytool and requested a certificate from Verisign. After this is imported (I'm waiting on delivery from verisign), how would I configure Tomcat to route traffic from http://domain.com:8443 to https://domain.com? Just making sure you didn't mistype: did you mean route traffic from https://domain.com:8443 to https://domain.com? If you really meant http://domain.com:8443 - https://domain.com then it's easy to set up a redirect by simply doing: response.sendRedirect(https://domain.com; + request.getRequestURI()); I suspect you meant that you wanted to use the default port of 443 for HTTPS traffic once you have a legit, signed certificate from a CA. See Mark's and Pid's responses for how to do that. The best resource is http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html If you are on a *NIX platform, I highly recommend using 'jsvc' (it allows non-root use of ports lower than 1025) which is available as source code in your Tomcat distribution as bin/jsvc.tar.gz. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksiaZ4ACgkQ9CaO5/Lv0PBa+wCgkguavPSHwN9Ff5SeJ8v5vJcU VV8AnRMWf19EOr/mJC6viF35hqf+XhOe =LRh+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
Should the port redirects for Connector 8080 and 8009 also be changed to 443? a On Fri, Dec 11, 2009 at 6:59 AM, Pid p...@pidster.com wrote: On 11/12/2009 11:47, Adria Stembridge wrote: I'm setting up a standalone instance of Tomcat with SSL. Tomcat5 is installed on the RHEL5 box and the sample pages load fine. I created a csr using keytool and requested a certificate from Verisign. After this is imported (I'm waiting on delivery from verisign), how would I configure Tomcat to route traffic from http://domain.com:8443 to https://domain.com ? Thank you. Tomcat 5.5 or Tomcat 5.0? The latter is no longer supported. Change the port of the Connector from 8443 to 443, assuming you have root rights (required to configure a port below 1024). p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
I've updated the connector as follows: Connector port=8080 redirectPort=8443 minSpareThreads=25 connectionTimeout=2 maxSpareThreads=75 maxThreads=150 /Connector Connector port=443 scheme=https secure=true keystoreFile=/my/secret/keystore keystorePass=mysecretpassword SSLEnabled=true sslProtocol=TLS maxSpareThreads=75 maxThreads=150 minSpareThreads=25 clientAuth=false /Connector And restarted Tomcat5. (I am running Tomcat 5.5 btw). Requesting the url https://mydomain.org returns the apache www page, not the tomcat default page. If I access with https://mydomain.org:8443, I get the tomcat page. No pages will be served with apache www, so I want the tomcat pages to appear over port 80 and 443. Ports 80, 8080, 443 and 8443 are allowed through the firewall. What else am I missing? a On Fri, Dec 11, 2009 at 2:42 PM, Adria Stembridge adrya.stembri...@gmail.com wrote: Should the port redirects for Connector 8080 and 8009 also be changed to 443? a On Fri, Dec 11, 2009 at 6:59 AM, Pid p...@pidster.com wrote: On 11/12/2009 11:47, Adria Stembridge wrote: I'm setting up a standalone instance of Tomcat with SSL. Tomcat5 is installed on the RHEL5 box and the sample pages load fine. I created a csr using keytool and requested a certificate from Verisign. After this is imported (I'm waiting on delivery from verisign), how would I configure Tomcat to route traffic from http://domain.com:8443 to https://domain.com? Thank you. Tomcat 5.5 or Tomcat 5.0? The latter is no longer supported. Change the port of the Connector from 8443 to 443, assuming you have root rights (required to configure a port below 1024). p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adria, On 12/11/2009 2:48 PM, Adria Stembridge wrote: I've updated the connector as follows: Connector port=8080 redirectPort=8443 minSpareThreads=25 connectionTimeout=2 maxSpareThreads=75 maxThreads=150 /Connector If you're moving to :443, why not also move to :80? Connector port=443 scheme=https secure=true keystoreFile=/my/secret/keystore keystorePass=mysecretpassword SSLEnabled=true sslProtocol=TLS maxSpareThreads=75 maxThreads=150 minSpareThreads=25 clientAuth=false /Connector That looks good. And restarted Tomcat5. (I am running Tomcat 5.5 btw). Requesting the url https://mydomain.org returns the apache www page, not the tomcat default page. If you get the Apache httpd welcome page, then Apache httpd is listening on port 443, so your Tomcat configuration isn't going to work. You need to tell Apache httpd /not/ to listen to port 443 (usually by simply telling httpd not to serve https). Any reason you are using Apache httpd, here, at all? If I access with https://mydomain.org:8443, I get the tomcat page. This behavior does not match your Tomcat configuration above. Did you post all of your Connector elements? If so, Tomcat isn't using the configuration file you think it is. If Apache httpd is really listening to port 443, then Tomcat should not have been able to startup in the above configuration because of a port conflict. No pages will be served with apache www, so I want the tomcat pages to appear over port 80 and 443. If Apache httpd is not needed, shut it down and disable it. In fact, uninstall it if you don't need it. Ports 80, 8080, 443 and 8443 are allowed through the firewall. You shouldn't need 8080 and 8443 at all: if you just want Tomcat to serve both ports 80 and 443, then you need to: 1. Disable / uninstall Apache httpd 2. Change the above Tomcat configuration for your HTTP connector to use port=80 instead of port=8080 What else am I missing? That should be about it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksiqiEACgkQ9CaO5/Lv0PA3ZACfSxHJMarjNW1Uy3APtmTICKJt sUgAoJJs6Mp85aFl+VZkjitCQtWJh6/K =+Jkp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New to Tomcat -- SSL
Any reason you are using Apache httpd, here, at all? None - I'd prefer not using it at all if possible. If Apache httpd is not needed, shut it down and disable it. In fact, uninstall it if you don't need it. Perfect. Ports 80, 8080, 443 and 8443 are allowed through the firewall. You shouldn't need 8080 and 8443 at all: if you just want Tomcat to serve both ports 80 and 443, then you need to: 1. Disable / uninstall Apache httpd 2. Change the above Tomcat configuration for your HTTP connector to use port=80 instead of port=8080 Should the connectors for port 8009 be left alone? What about the port redirects, should these all point to 443 instead of 8443?
Re: New to Tomcat -- SSL
Well, I appear to have something wrong. Pages are not served over 80 or 443 after updating server.xml and iptables. [linux]# netstat -an | grep LISTEN tcp0 0 0.0.0.0:897 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:250.0.0.0:* LISTEN tcp0 0 127.0.0.1:6010 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:70030.0.0.0:* LISTEN tcp0 0 :::127.0.0.1:8005 :::* LISTEN tcp0 0 :::22 :::* LISTEN tcp0 0 ::1:6010:::* LISTEN tcp0 0 :::7003 :::* LISTEN [linux]# Not listening on 80 or 443. [linux]# more /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT [linux]# But firewall rules should open these two ports. Connectors: Connector port=80 redirectPort=8443 minSpareThreads=25 connectionTimeout=2 maxSpareThreads=75 maxThreads=150 /Connector Connector port=443 scheme=https secure=true keystoreFile=/my/secret/keystore keystorePass=mysecretpassword SSLEnabled=true sslProtocol=TLS maxSpareThreads=75 maxThreads=150 minSpareThreads=25 clientAuth=false /Connector Connector port=8009 redirectPort=8443 secure=true connectionTimeout=0 threadPriority=5 connectionUploadTimeout=0 connectionLinger=0 maxSpareThreads=50 maxThreads=200 maxKeepAliveRequests=100 disableUploadTimeout=false I may be missing something obvious - but what?
Re: New to Tomcat -- SSL
Adria Stembridge wrote: Well, I appear to have something wrong. Pages are not served over 80 or 443 after updating server.xml and iptables. [linux]# netstat -an | grep LISTEN try netstat -pan, which will also give you the PID of the process owning the listening socket. ... tcp0 0 :::127.0.0.1:8005 :::* LISTEN ... [linux]# Not listening on 80 or 443. Nor on 8009 either, which it should according to your Connector tags shown. But it does seem to be listening on 8005, which is the Tomcat shutdown port usually (the one mentioned in the Server .. tag). For netstat, the firewall/iptables configuration should be irrelevant, no ? It only (possibly) blocks external attempts to connect to these ports. ... I may be missing something obvious - but what? Are you sure there are not just !-- comment -- signs around your Connector tags ? Don't the Tomcat logs say anything helpful ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
Christopher Schultz wrote: On 4/13/2009 1:55 PM, Liraz Siri wrote: We're proud to announce the release of TurnKey Apache Tomcat, an installable live CD of Apache Tomcat that can run on real hardware in addition to most types of virtual machines (e.g., VMWare, VirtualBox, Parallels, Xen HVM). It is designed to provide users with a pre-integrated, auto-updating, turn-key operating system environment that is carefully built from the ground up with the minimum components needed to run Apache Tomcat with maximum usability, efficiency, and security. If your goal was a minimal set of components, why did you choose to include Apache httpd + mod_jk, neither of which are required to run Tomcat. You're right Chris, you don't _need_ Apache, and therefore mod_jk to run Tomcat. Tomcat can listen (and does by default, though we turned it off for security reasons) and answer requests directly. OTOH, we consulted with a few Java people who told us you usually (in a production setting) want a load-balancer (eg. Apache) in front of your Tomcat node[s] to: A) improve performance B) make the setup easier to maintain C) provide a way to serve static content In the future we might create a more minimal Tomcat node appliance to which a front-end load balancer appliance could offload traffic, but that needs more thought... Cheers, Liraz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
On Mon, Apr 20, 2009 at 10:17 AM, Liraz Siri li...@turnkeylinux.org wrote: Christopher Schultz wrote: If your goal was a minimal set of components, why did you choose to include Apache httpd + mod_jk, neither of which are required to run Tomcat. You're right Chris, you don't _need_ Apache, and therefore mod_jk to run Tomcat. Tomcat can listen (and does by default, though we turned it off for security reasons) and answer requests directly. OTOH, we consulted with a few Java people who told us you usually (in a production setting) want a load-balancer (eg. Apache) in front of your Tomcat node[s] to: Apparently you haven't consulted any tomcat-using java developers, since A) improve performance tomcat standalone performs better in most setups (yes, yes sendfile myth is there too, but the performance measurements shows that tomcats plain old java connector performs better) B) make the setup easier to maintain how can adding unneeded complexitty make things easier? C) provide a way to serve static content See A) In the future we might create a more minimal Tomcat node appliance to which a front-end load balancer appliance could offload traffic, but that needs more thought... If you are really looking for a useful load-balanced appliance check for keepalived or pound. regards Leon Cheers, Liraz - 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: Announcing new Apache Tomcat installable Live CD appliance
Leon Rosenberg wrote: Apparently you haven't consulted any tomcat-using java developers, since That's sort of why we posted to tomcat-users. We're not Apache Tomcat experts ourselves, so we figured the community would have some good feedback on our first stab at a Tomcat appliance. tomcat standalone performs better in most setups (yes, yes sendfile myth is there too, but the performance measurements shows that tomcats plain old java connector performs better) Ah. We seem to have been misinformed. If you are really looking for a useful load-balanced appliance check for keepalived or pound. Thanks for the feedback. Really, this is exactly what we need to improve the next version. If anyone else has any feedback on our beta appliance or good ideas for the next version, speak up! Cheers, Liraz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
2009/4/20 Markus Schönhaber tomcat-us...@list-post.mks-mail.de: Leon Rosenberg: tomcat standalone performs better in most setups (yes, yes sendfile myth is there too, but the performance measurements shows that tomcats plain old java connector performs better) Which performance measurements do show that? Tomcat: The Definitive Guide, Second Edition http://oreilly.com/catalog/9780596101060/chapter/index.html Regards mks regards Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
Leon Rosenberg: tomcat standalone performs better in most setups (yes, yes sendfile myth is there too, but the performance measurements shows that tomcats plain old java connector performs better) Which performance measurements do show that? Regards mks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Liraz, On 4/20/2009 4:17 AM, Liraz Siri wrote: You're right Chris, you don't _need_ Apache, and therefore mod_jk to run Tomcat. Tomcat can listen (and does by default, though we turned it off for security reasons) and answer requests directly. OTOH, we consulted with a few Java people who told us you usually (in a production setting) want a load-balancer (eg. Apache) in front of your Tomcat node[s] to: A) improve performance B) make the setup easier to maintain C) provide a way to serve static content I would argue that A is best achieved by a hardware load balancer rather than Apache httpd, B is actually /not/ achieved by the addition of Apache httpd (more components means more complexity which means higher maintenance costs), and C is served perfectly by Tomcat alone. If I were you, I would provide a Tomcat-only appliance and a separate load-balancer appliance that could be trivially combined to achieve all your goals. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkns1UQACgkQ9CaO5/Lv0PCxxACggT1ClMwEmKjqGFPh8qrcd9eM rmcAoJeLt1OvGliOJVZ0OrwMQknE1MZ1 =Pcjo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
Christopher Schultz wrote: I would argue that A is best achieved by a hardware load balancer rather than Apache httpd, B is actually /not/ achieved by the addition of Apache httpd (more components means more complexity which means higher maintenance costs), and C is served perfectly by Tomcat alone. If I were you, I would provide a Tomcat-only appliance and a separate load-balancer appliance that could be trivially combined to achieve all your goals. Quite right. We forwarded some of the feedback we received on the list to some of the people consulted with and it seems there was a misunderstanding on our part. It doesn't make sense for the load balancer and Tomcat to be in the same appliance. We'll be fixing that in the next version. Cheers, Liraz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Liraz, On 4/20/2009 4:25 PM, Liraz Siri wrote: Christopher Schultz wrote: I would argue that A is best achieved by a hardware load balancer rather than Apache httpd, B is actually /not/ achieved by the addition of Apache httpd (more components means more complexity which means higher maintenance costs), and C is served perfectly by Tomcat alone. If I were you, I would provide a Tomcat-only appliance and a separate load-balancer appliance that could be trivially combined to achieve all your goals. Quite right. We forwarded some of the feedback we received on the list to some of the people consulted with and it seems there was a misunderstanding on our part. It doesn't make sense for the load balancer and Tomcat to be in the same appliance. We'll be fixing that in the next version. Sounds good! Don't get me wrong: I hadn't intended to merely complain. I'm just applying some of the best practices I've learned through the years both working on my own projects and helping out folks on this list. I think a Tomcat appliance is a great idea. Remember to use APR for SSL! :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkns5PsACgkQ9CaO5/Lv0PDEGQCfZtjPc28OsS9Tt+dIAty2RCI+ vWIAn17EENMpkbQdI6XF7+dWhPL6XbpR =uuRA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Announcing new Apache Tomcat installable Live CD appliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Liraz, On 4/13/2009 1:55 PM, Liraz Siri wrote: We're proud to announce the release of TurnKey Apache Tomcat, an installable live CD of Apache Tomcat that can run on real hardware in addition to most types of virtual machines (e.g., VMWare, VirtualBox, Parallels, Xen HVM). It is designed to provide users with a pre-integrated, auto-updating, turn-key operating system environment that is carefully built from the ground up with the minimum components needed to run Apache Tomcat with maximum usability, efficiency, and security. If your goal was a minimal set of components, why did you choose to include Apache httpd + mod_jk, neither of which are required to run Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknoodEACgkQ9CaO5/Lv0PD8XwCfSpcIBqH9Ls4pi8u1Vby9Phrh yXEAoJyFHX8aB+hELPEiDvwtnbm3ZZrp =u4jf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Announcing new Apache Tomcat installable Live CD appliance
Hi everyone, I'm one of the developers for TurnKey Linux, a community oriented open source project developing a family of free, Ubuntu-based installable Live CDs which are lightweight and optimized for ease of use in server-type usage scenarios (e.g., LAMP, Joomla CMS, Drupal, Ruby on Rails): http://www.turnkeylinux.org/appliances We're proud to announce the release of TurnKey Apache Tomcat, an installable live CD of Apache Tomcat that can run on real hardware in addition to most types of virtual machines (e.g., VMWare, VirtualBox, Parallels, Xen HVM). It is designed to provide users with a pre-integrated, auto-updating, turn-key operating system environment that is carefully built from the ground up with the minimum components needed to run Apache Tomcat with maximum usability, efficiency, and security. Basically this is an extremely easy way to get up and running with Apache Tomcat in just a few minutes. Feature highlights: * Auto-updated daily with latest security patches * SSL support out of the box * Elegant Web administration interface (Mac OS X themed) * Minimal footprint (212MB) Full details: http://www.turnkeylinux.org/appliances/tomcat BTW, this type of pre-integrated, ready-to-use system is typically called a software appliance: http://en.wikipedia.org/wiki/Software_appliance Take a look and tell us what you think! Cheers, Liraz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What new in Tomcat 6.0 ?
Hi All!! I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0 compared to the last version. Thanks in advance Regards Ashish
Re: What new in Tomcat 6.0 ?
Might give you some ideas... http://tomcat.apache.org/whichversion.html On 9/5/07, Ashish Jain [EMAIL PROTECTED] wrote: Hi All!! I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0 compared to the last version. Thanks in advance Regards Ashish - 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: What new in Tomcat 6.0 ?
It implements the latest Servlet and JSP specifications (2.5 2.1 vs 2.4 2.0), and also has memory optimizations, advanced IO and refactored clustering. http://tomcat.apache.org/whichversion.html#Apache%20Tomcat%206.x On 9/5/07, Ashish Jain [EMAIL PROTECTED] wrote: Hi All!! I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0 compared to the last version. Thanks in advance Regards Ashish -- \ \ Peter Boughton blog.bpsite.net / /
New to Tomcat
Hi there... Running Fedora Core 4 and installed Tomcat via yum installs I'm trying to get Nutch search engine working and keep getting the following errors. I'm told by the nutch mailing list that this is a specific issue to Tomcat?? HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.compiler.DefaultErrorHandler.javacError(java.lang.Stri ng, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.ErrorDispatcher.javacError(java.lang.String, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String, java.lang.Throwable, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServ letRequest, javax.servlet.http.HttpServletResponse) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (/usr/lib/libservletapi5-5.0.30.jar.so) org.apache.catalina.valves.ErrorReportValve.invoke(org.apache.catalina.R equest, org.apache.catalina.Response, org.apache.catalina.ValveContext) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.tomcat5.CoyoteAdapter.service(org.apache.coyote.Reques t, org.apache.coyote.Response) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.http11.Http11Processor.process(java.io.InputStream, java.io.OutputStream) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection(org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.tomcat.util.net.TcpWorkerThread.runIt(java.lang.Object[]) (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0) root cause Error starting modern compiler org.apache.tools.ant.taskdefs.compilers.Javac13.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.compile() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String, java.lang.Throwable, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServ letRequest, javax.servlet.http.HttpServletResponse) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (/usr/lib/libservletapi5-5.0.30.jar.so) org.apache.catalina.valves.ErrorReportValve.invoke(org.apache.catalina.R equest, org.apache.catalina.Response, org.apache.catalina.ValveContext) (/usr/lib/libcatalina-5.0.30.jar.so)
Re: New to Tomcat
root cause Error starting modern compiler org.apache.tools.ant.taskdefs.compilers.Javac13.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.compile() check that your JAVA_HOME points to a jdk, not a jre. It may be jasper compiler don't find a suitable java compiler. Btw, this is quite curious: /usr/lib/libjasper5-compiler-5.0.30.jar.so You should probably use the official tomcat release files available on apache.org to be sure it's not a distro related problem. Please also note 5.0.30 is a beta, latest 5.0.x tomcat stable version is 5.0.28 The .jar.so extension is . frightening :) Paul Stewart a écrit : Hi there... Running Fedora Core 4 and installed Tomcat via yum installs I'm trying to get Nutch search engine working and keep getting the following errors. I'm told by the nutch mailing list that this is a specific issue to Tomcat?? HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.compiler.DefaultErrorHandler.javacError(java.lang.Stri ng, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.ErrorDispatcher.javacError(java.lang.String, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String, java.lang.Throwable, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServ letRequest, javax.servlet.http.HttpServletResponse) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (/usr/lib/libservletapi5-5.0.30.jar.so) org.apache.catalina.valves.ErrorReportValve.invoke(org.apache.catalina.R equest, org.apache.catalina.Response, org.apache.catalina.ValveContext) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.tomcat5.CoyoteAdapter.service(org.apache.coyote.Reques t, org.apache.coyote.Response) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.http11.Http11Processor.process(java.io.InputStream, java.io.OutputStream) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection(org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.tomcat.util.net.TcpWorkerThread.runIt(java.lang.Object[]) (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0) root cause Error starting modern compiler org.apache.tools.ant.taskdefs.compilers.Javac13.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.compile() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String,
Re: New to Tomcat
David Delbecq ha scritto: Btw, this is quite curious: /usr/lib/libjasper5-compiler-5.0.30.jar.so You should probably use the official tomcat release files available on apache.org to be sure it's not a distro related problem. Please also note 5.0.30 is a beta, latest 5.0.x tomcat stable version is 5.0.28 The .jar.so extension is . frightening :) It is compiled natively with GCJ, maybe this is the cause of his problem. Paul, try to use Tomcat with Sun's JVM and see if you have the same problem. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New to Tomcat
I'm guess tomcat compiled into native code. I may wrong but in fedora5 all of Apache Jakarta Project and Apache Geronimo are compiled in native code. As for me it's a bad idea On 4/5/06, David Delbecq [EMAIL PROTECTED] wrote: root cause Error starting modern compiler org.apache.tools.ant.taskdefs.compilers.Javac13.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.compile() check that your JAVA_HOME points to a jdk, not a jre. It may be jasper compiler don't find a suitable java compiler. Btw, this is quite curious: /usr/lib/libjasper5-compiler-5.0.30.jar.so You should probably use the official tomcat release files available on apache.org to be sure it's not a distro related problem. Please also note 5.0.30 is a beta, latest 5.0.x tomcat stable version is 5.0.28 The .jar.so extension is . frightening :) Paul Stewart a écrit : Hi there... Running Fedora Core 4 and installed Tomcat via yum installs I'm trying to get Nutch search engine working and keep getting the following errors. I'm told by the nutch mailing list that this is a specific issue to Tomcat?? HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.compiler.DefaultErrorHandler.javacError(java.lang.Stri ng, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.ErrorDispatcher.javacError(java.lang.String, java.lang.Exception) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.H ttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String, java.lang.Throwable, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServ letRequest, javax.servlet.http.HttpServletResponse) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (/usr/lib/libservletapi5-5.0.30.jar.so) org.apache.catalina.valves.ErrorReportValve.invoke(org.apache.catalina.R equest, org.apache.catalina.Response, org.apache.catalina.ValveContext) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.tomcat5.CoyoteAdapter.service(org.apache.coyote.Reques t, org.apache.coyote.Response) (/usr/lib/libcatalina-5.0.30.jar.so) org.apache.coyote.http11.Http11Processor.process(java.io.InputStream, java.io.OutputStream) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection(org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) (/usr/lib/libtomcat-http11-5.0.30.jar.so) org.apache.tomcat.util.net.TcpWorkerThread.runIt(java.lang.Object[]) (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() (/tmp/libtomcat-util-5.0.30.jar.so9a2vfs.so) java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0) root cause Error starting modern compiler org.apache.tools.ant.taskdefs.compilers.Javac13.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.compile() (/usr/lib/libant-1.6.2.jar.so) org.apache.tools.ant.taskdefs.Javac.execute() (/usr/lib/libant-1.6.2.jar.so) org.apache.jasper.compiler.Compiler.generateClass(java.lang.String[]) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile(boolean) (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.compiler.Compiler.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.JspCompilationContext.compile() (/usr/lib/libjasper5-compiler-5.0.30.jar.so) org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.H ttpServletRequest,
new versions Tomcat
Hi, I'm new here i'm having problems with new versions of Tomcat. I was using tomcat 5.0.27 and i have a web application made in Java. My code has to get URL using the following code: String url = request.getRequestURL().toString(); I use Struts and my URL is http://localhost:8080/terp/list.client.do?metodo=insert. The code above returned the string http://localhost:8080/terp/list.client.do?metodo=insert;. That's what i want. When i updated tomcat (I tested with tomcat 5.5.9 and 5.5.15), the code did not work anymore. The code now is returning the path of the page like http://localhost:7070/terp/WEB-INF/templates/client/ListClient.vm;. And now?? what can i do to solve this How can i get the correct URL??? Thanks and I'm waiting for your answer. - Yahoo! doce lar. Faça do Yahoo! sua homepage.
Re: new versions Tomcat
Lucio Ribeiro wrote: Hi, I'm new here i'm having problems with new versions of Tomcat. I was using tomcat 5.0.27 and i have a web application made in Java. My code has to get URL using the following code: String url = request.getRequestURL().toString(); I use Struts and my URL is http://localhost:8080/terp/list.client.do?metodo=insert. The code above returned the string http://localhost:8080/terp/list.client.do?metodo=insert;. That's what i want. When i updated tomcat (I tested with tomcat 5.5.9 and 5.5.15), the code did not work anymore. The code now is returning the path of the page like http://localhost:7070/terp/WEB-INF/templates/client/ListClient.vm;. And now?? what can i do to solve this How can i get the correct URL??? Thanks and I'm waiting for your answer. This is a result of fixing bug 28222 (http://issues.apache.org/bugzilla/show_bug.cgi?id=28222). Older versions of Tomcat were not compliant with section SRV.8.4 of the servlet specification. The behaviour you now see is spec compliant. There have been a few other reports related to this change. For example: http://issues.apache.org/bugzilla/show_bug.cgi?id=35425 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
From Websphere to Tomcat -- New to Tomcat
Hello All, I am new to Tomcat, coming from a Websphere background. I am using Eclipse with the Tomcat plug-in installed. I can successfully start the server, everything seems OK so far. A few questions. 1. On Websphere I had a web.xml file where I would define servlet entry points, context parameters, etc. I am assuming that I create this file by hand (Websphere created it automatically) and it goes in WEB-INF 2. performTask vs doGet - I have always used PerformTask rather than doGet. But all of the examples I find use doGet. Does Tomcat recognize PerformTask? 3. I am putting my packages and source in the work Directory 4. Where do JSP pages go? 5. I see that I need to export my project as a .war file. Where does this .war file go to run it? 6. Is there a way that I can run the .war file from directly in Eclipse? Thanks for the information. -jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From Websphere to Tomcat -- New to Tomcat
I am not a very knowledgeable user and am not a java programmer, but I can actually answer a couple of these questions. 1. The web.xml file for your application typically goes in the lib directory under WEB-INF, which is under the container you have created for your application. The typical thing is to create a container under webapps, say call it newapp. Then your WEB-INF goes under there, and the lib directory with the web.xml file under that. 3. You should not be putting things in the work directory. Tomcat automatically puts what it needs to from the application there and sometimes you need to clean up that directory in order to get a new version of the code running, but it should not be where your code resides. 4. JSPs typically go in the same newapp directory webapps as a 'jsp' directory on the same level as WEB-INF. 5. There was a recent post about war files, you can refer to the archives and find it. It was a couple days ago. Good luck, hope this helped a bit. Becky Jason T. Slack wrote: Hello All, I am new to Tomcat, coming from a Websphere background. I am using Eclipse with the Tomcat plug-in installed. I can successfully start the server, everything seems OK so far. A few questions. 1. On Websphere I had a web.xml file where I would define servlet entry points, context parameters, etc. I am assuming that I create this file by hand (Websphere created it automatically) and it goes in WEB-INF 2. performTask vs doGet - I have always used PerformTask rather than doGet. But all of the examples I find use doGet. Does Tomcat recognize PerformTask? 3. I am putting my packages and source in the work Directory 4. Where do JSP pages go? 5. I see that I need to export my project as a .war file. Where does this .war file go to run it? 6. Is there a way that I can run the .war file from directly in Eclipse? Thanks for the information. -jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
