Re: "Invalid Server SSL Protocol" on Tomcat 8.0.15 with Tomcat Native library 1.1.32 and APR 1.5.1
2014-12-18 4:12 GMT+03:00 Mike Wertheim : > I'm trying to upgrade from Tomcat 7.0.41 with APR to Tomcat 8.0.15 with > APR. (I'm using JDK 1.8.0.25 on CentOS.) > > My first step was to upgrade to Tomcat Native library 1.1.32 and APR 1.5.1 > while still using Tomcat 7.0.41. This combination works great. My webapp > starts up and is accessible using either SSL or non-SSL. > > Next I upgraded to Tomcat 8.0.15 (again with Tomcat Native library 1.1.32 > and APR 1.5.1). Tomcat 8.0.15 starts up, and the first lines of > catalina.out are a message that shows that Tomcat Native library 1.1.32 and > APR 1.5.1 are indeed in use. My webapp starts up and is accessible using > non-SSL requests, but SSL requests don't work. > > When I saw that SSL wasn't working, I looked in catalina.out and saw this: > > org.apache.coyote.AbstractProtocol.init Failed to initialize end point > associated with ProtocolHandler ["http-apr-8443"] > java.lang.Exception: Unable to create SSLContext. Check that SSLEngine is > enabled in the AprLifecycleListener, the AprLifecycleListener has > initialised correctly and that a valid SSLProtocol has been specified > at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730) > [...] > Caused by: java.lang.Exception: Invalid Server SSL Protocol > (error::lib(0):func(0):reason(0 > )) > at org.apache.tomcat.jni.SSLContext.make(Native Method) > at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527) > > > The SSL Connector in server.xml looks like this: > maxKeepAliveRequests="3" keepAliveTimeout="3000" > scheme="https" secure="true" SSLEnabled="true" > SSLCertificateFile="/home/scuser/ssl/cert.crt" > SSLCertificateKeyFile="/home/scuser/ssl/cert.key" > > SSLCertificateChainFile="/home/scuser/ssl/intermediateCA.cer" > clientAuth="false" sslProtocol="TLS"/> > > Can anyone see what might be going wrong? The correct property name for APR connector is "SSLProtocol", not sslProtocol. The spelling matters. SSLProtocol="TLSv1+TLSv1.1+TLSv1.2" I think that you would also like to configure SSLCipherSuite http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#SSL_Support_-_APR/Native Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Invalid Server SSL Protocol" on Tomcat 8.0.15 with Tomcat Native library 1.1.32 and APR 1.5.1
Thanks for the suggestion. I made my SSL Connector look more like the Connector you sent, and I am still getting the exact same "Invalid Server SSL Protocol" error. The changes that I made, which had no effect, were: - added protocol="org.apache.coyote.http11.Http11AprProtocol" - changed sslProtocol from "TLS" to "TLSv1.2" - changed SSLCertificateChainFile to SSLCACertificateFile On Wed, Dec 17, 2014 at 6:20 PM, Sanaullah wrote: > > Hi Mike. > > here is my working configuration with APR. > > >protocol="org.apache.coyote.http11.Http11AprProtocol" >maxThreads="150" SSLEnabled="true" scheme="https" > secure="true" >clientAuth="true" sslProtocol="TLSv1.2" > SSLCertificateFile="/opt/_cdrom_apache/certs/dev-apr.pem" >SSLCertificateKeyFile="/opt/_cdrom_apache/certs/key.pem" >SSLCACertificateFile="/opt/_cdrom_apache/certs/CA.pem" >/> > > I hope this will work for you. > > Regards, > Sanaullah > > > On Thu, Dec 18, 2014 at 6:15 AM, Mike Wertheim wrote: > > > > I should have included this in the previous message. > > > > The AprLifecycleListener is declared in server.xml like this: > >> SSLEngine="on" /> > > > > > > > > > > On Wed, Dec 17, 2014 at 5:12 PM, Mike Wertheim wrote: > > > > > > I'm trying to upgrade from Tomcat 7.0.41 with APR to Tomcat 8.0.15 with > > > APR. (I'm using JDK 1.8.0.25 on CentOS.) > > > > > > My first step was to upgrade to Tomcat Native library 1.1.32 and APR > > 1.5.1 > > > while still using Tomcat 7.0.41. This combination works great. My > > webapp > > > starts up and is accessible using either SSL or non-SSL. > > > > > > Next I upgraded to Tomcat 8.0.15 (again with Tomcat Native library > 1.1.32 > > > and APR 1.5.1). Tomcat 8.0.15 starts up, and the first lines of > > > catalina.out are a message that shows that Tomcat Native library 1.1.32 > > and > > > APR 1.5.1 are indeed in use. My webapp starts up and is accessible > using > > > non-SSL requests, but SSL requests don't work. > > > > > > When I saw that SSL wasn't working, I looked in catalina.out and saw > > this: > > > > > > org.apache.coyote.AbstractProtocol.init Failed to initialize end point > > > associated with ProtocolHandler ["http-apr-8443"] > > > java.lang.Exception: Unable to create SSLContext. Check that SSLEngine > > is > > > enabled in the AprLifecycleListener, the AprLifecycleListener has > > > initialised correctly and that a valid SSLProtocol has been specified > > > at > > > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532) > > > at > > > > > > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730) > > > [...] > > > Caused by: java.lang.Exception: Invalid Server SSL Protocol > > > (error::lib(0):func(0):reason(0 > > > )) > > > at org.apache.tomcat.jni.SSLContext.make(Native Method) > > > at > > > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527) > > > > > > > > > The SSL Connector in server.xml looks like this: > > > > > maxKeepAliveRequests="3" keepAliveTimeout="3000" > > > scheme="https" secure="true" SSLEnabled="true" > > > SSLCertificateFile="/home/scuser/ssl/cert.crt" > > > SSLCertificateKeyFile="/home/scuser/ssl/cert.key" > > > > > > SSLCertificateChainFile="/home/scuser/ssl/intermediateCA.cer" > > > clientAuth="false" sslProtocol="TLS"/> > > > > > > Can anyone see what might be going wrong? > > > > > > > > > Thanks, > > > Mike > > > > > > > > >
Re: "Invalid Server SSL Protocol" on Tomcat 8.0.15 with Tomcat Native library 1.1.32 and APR 1.5.1
Hi Mike. here is my working configuration with APR. I hope this will work for you. Regards, Sanaullah On Thu, Dec 18, 2014 at 6:15 AM, Mike Wertheim wrote: > > I should have included this in the previous message. > > The AprLifecycleListener is declared in server.xml like this: >SSLEngine="on" /> > > > > > On Wed, Dec 17, 2014 at 5:12 PM, Mike Wertheim wrote: > > > > I'm trying to upgrade from Tomcat 7.0.41 with APR to Tomcat 8.0.15 with > > APR. (I'm using JDK 1.8.0.25 on CentOS.) > > > > My first step was to upgrade to Tomcat Native library 1.1.32 and APR > 1.5.1 > > while still using Tomcat 7.0.41. This combination works great. My > webapp > > starts up and is accessible using either SSL or non-SSL. > > > > Next I upgraded to Tomcat 8.0.15 (again with Tomcat Native library 1.1.32 > > and APR 1.5.1). Tomcat 8.0.15 starts up, and the first lines of > > catalina.out are a message that shows that Tomcat Native library 1.1.32 > and > > APR 1.5.1 are indeed in use. My webapp starts up and is accessible using > > non-SSL requests, but SSL requests don't work. > > > > When I saw that SSL wasn't working, I looked in catalina.out and saw > this: > > > > org.apache.coyote.AbstractProtocol.init Failed to initialize end point > > associated with ProtocolHandler ["http-apr-8443"] > > java.lang.Exception: Unable to create SSLContext. Check that SSLEngine > is > > enabled in the AprLifecycleListener, the AprLifecycleListener has > > initialised correctly and that a valid SSLProtocol has been specified > > at > > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532) > > at > > > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730) > > [...] > > Caused by: java.lang.Exception: Invalid Server SSL Protocol > > (error::lib(0):func(0):reason(0 > > )) > > at org.apache.tomcat.jni.SSLContext.make(Native Method) > > at > > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527) > > > > > > The SSL Connector in server.xml looks like this: > > > maxKeepAliveRequests="3" keepAliveTimeout="3000" > > scheme="https" secure="true" SSLEnabled="true" > > SSLCertificateFile="/home/scuser/ssl/cert.crt" > > SSLCertificateKeyFile="/home/scuser/ssl/cert.key" > > > > SSLCertificateChainFile="/home/scuser/ssl/intermediateCA.cer" > > clientAuth="false" sslProtocol="TLS"/> > > > > Can anyone see what might be going wrong? > > > > > > Thanks, > > Mike > > > > >
Re: About scanAllDirectories,JarScanner and expanded JAR
> > > Which part of "WEB-INF/lib is only ever scanned for JARs. Everything > else is ignored." did you not understand? Yes, I see that only WEB-INF/lib/*.jar files are scanned. > > And which directories/classpath the document indicates when it saying > "If > > true, any directories found on the classpath will be checked to see if > they > > are expanded JAR files" , if it "won't work for either of those > > directories"? > > As per the docs, scanAllDirectories applies to directories found on the > class path not to WEB-INF/lib since it is not on the class path. > (WEB-INF/lib/*.jar is on the class path and that is not a directory). > > And for WEB-INF/classes, only unpacked classes and resources(without any top-level non-package-name directories) are accepted, an "expanded JAR file" is not accepted here. The difference between "unpacked classes" and "expanded JAR file" is whether there is a top-level folder outside plus a sibling META-INF folder beside the "unpacked classes", is it right? Then where else should I put an "expanded JAR file", except WEB-INF/lib and WEB-INF/classes? How to define the class path? I will be very appreciative if any of you could give me an example to illustrate the usage of "scanAllDirectories" and "expanded JAR file". Regards, Nan
Re: "Invalid Server SSL Protocol" on Tomcat 8.0.15 with Tomcat Native library 1.1.32 and APR 1.5.1
I should have included this in the previous message. The AprLifecycleListener is declared in server.xml like this: On Wed, Dec 17, 2014 at 5:12 PM, Mike Wertheim wrote: > > I'm trying to upgrade from Tomcat 7.0.41 with APR to Tomcat 8.0.15 with > APR. (I'm using JDK 1.8.0.25 on CentOS.) > > My first step was to upgrade to Tomcat Native library 1.1.32 and APR 1.5.1 > while still using Tomcat 7.0.41. This combination works great. My webapp > starts up and is accessible using either SSL or non-SSL. > > Next I upgraded to Tomcat 8.0.15 (again with Tomcat Native library 1.1.32 > and APR 1.5.1). Tomcat 8.0.15 starts up, and the first lines of > catalina.out are a message that shows that Tomcat Native library 1.1.32 and > APR 1.5.1 are indeed in use. My webapp starts up and is accessible using > non-SSL requests, but SSL requests don't work. > > When I saw that SSL wasn't working, I looked in catalina.out and saw this: > > org.apache.coyote.AbstractProtocol.init Failed to initialize end point > associated with ProtocolHandler ["http-apr-8443"] > java.lang.Exception: Unable to create SSLContext. Check that SSLEngine is > enabled in the AprLifecycleListener, the AprLifecycleListener has > initialised correctly and that a valid SSLProtocol has been specified > at > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730) > [...] > Caused by: java.lang.Exception: Invalid Server SSL Protocol > (error::lib(0):func(0):reason(0 > )) > at org.apache.tomcat.jni.SSLContext.make(Native Method) > at > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527) > > > The SSL Connector in server.xml looks like this: > maxKeepAliveRequests="3" keepAliveTimeout="3000" > scheme="https" secure="true" SSLEnabled="true" > SSLCertificateFile="/home/scuser/ssl/cert.crt" > SSLCertificateKeyFile="/home/scuser/ssl/cert.key" > > SSLCertificateChainFile="/home/scuser/ssl/intermediateCA.cer" > clientAuth="false" sslProtocol="TLS"/> > > Can anyone see what might be going wrong? > > > Thanks, > Mike > >
"Invalid Server SSL Protocol" on Tomcat 8.0.15 with Tomcat Native library 1.1.32 and APR 1.5.1
I'm trying to upgrade from Tomcat 7.0.41 with APR to Tomcat 8.0.15 with APR. (I'm using JDK 1.8.0.25 on CentOS.) My first step was to upgrade to Tomcat Native library 1.1.32 and APR 1.5.1 while still using Tomcat 7.0.41. This combination works great. My webapp starts up and is accessible using either SSL or non-SSL. Next I upgraded to Tomcat 8.0.15 (again with Tomcat Native library 1.1.32 and APR 1.5.1). Tomcat 8.0.15 starts up, and the first lines of catalina.out are a message that shows that Tomcat Native library 1.1.32 and APR 1.5.1 are indeed in use. My webapp starts up and is accessible using non-SSL requests, but SSL requests don't work. When I saw that SSL wasn't working, I looked in catalina.out and saw this: org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler ["http-apr-8443"] java.lang.Exception: Unable to create SSLContext. Check that SSLEngine is enabled in the AprLifecycleListener, the AprLifecycleListener has initialised correctly and that a valid SSLProtocol has been specified at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730) [...] Caused by: java.lang.Exception: Invalid Server SSL Protocol (error::lib(0):func(0):reason(0 )) at org.apache.tomcat.jni.SSLContext.make(Native Method) at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527) The SSL Connector in server.xml looks like this: Can anyone see what might be going wrong? Thanks, Mike
Re: Tomcat cluster with static membership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Theo, On 12/17/14 11:22 AM, Théo Chamley wrote: > Mark, things haven't changed on Tomcat8 for the logging properties, > your configuration did work. > > In the end, I had two problems: * My client did not have a > element in his web.xml This was going to be my suggestion. It's the most obvious thing that everyone misses. > * More importantly, the NioReceiver was not well configured. > > The "address" parameter as defined in the documentation > (http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-receiver.html) > > was more that what I thought. It is not only the binding address for the > receiver, it's also the address that will be advertised to the > other nodes of the cluster. I configured it to "0.0.0.0", > therefore the other node tried to connect to "0.0.0.0:". You > can see the problem... Replacing this address by a routable one > solved my problem. Even if it is quite logical, I think the > documentation could be clearer on this point. Patches, even to the documentation, are always welcome ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUkgc4AAoJEBzwKT+lPKRYHfEP/RfGoaALVVsHkkBvoW0FCIdE nwj2tvj5BvMOuZs3jAorDn6hcVNcgT9T/hQQGhAPLlIeJjjVYGBY/rS9n3Jk3QJc IlFSp8+GbjiNTVTo86F2zVFB/iAm3oGZsgSU5rgG4uZrrZFZEEUAPVRdkG5cS7U+ r9iEoh5sckqGVF3AjRPSFRg1Lk34FcSrnDYCEyi136zHES1KNDMWstgjHPvrx498 MTzxCA60LO+C9lkuzhtZ0Bo3A0P2WX+5LS314PCq1lal4a7p4P9JIzG8/QGhLxmH MJqxQISY8Y0fhxdZIBeMP7jjVRPFdtjhMH0D/jdqlNQ+rxsLEDZoBKtAX9dejfRj /MUbY7BjbhZ+lsIyEH0qOHUrVhEfW5Rl8EltPffFGWvHoogdG2+rCZeuBC4eU16Q 9vow9Hh//XLaqH+KYyMsuOF5NRp/xrKWvoE7WhHOTTcoAttCPAaYrCZXAL5wjKtU gYNc0KwRNg4loWHs/MMJr7F4nR93UOWzHVnvvGGpoDtMXkVHranQ63TF2Ly8Met+ WdGsae7gJA4NlNC8c36ipXxM2jc82DKxCtdarsstkcIQG/yWXMSrbtcT19CH0Dg3 5N04JezE40EBKahl5OK6V1Kk1pU6ikgZ+iAw/lyUE+hrXtLFNwiPKvEdvwq68vCu tss94Kk1ajUUTTbfVaNU =CN6B -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat on windows 2012 weirdness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 12/17/14 2:15 PM, Cris Berneburg - US wrote: > Ameer (and Chris) > > I discovered something else. When accessing the internal web site > by name, it does not work right. But when I access the web site by > IP address, it functions correctly! > >> If you are using IE9, it has a very useful utility in its >> developer tool to capture network traffic. Few simple steps to >> capture it: Press F12 --> Go to network tab--> start capturing >> You can save/export the captured data in an xml file and then can >> see everything going to-and-fro between your browser and server. > >> Compare the traffic when you are communicating from localhost, >> which you say is working fine, with the traffic when you are >> accessing from an outside client. Pay special attention to the >> headers section of the HTTP calls. > > Thanks for your suggestion. I tried the IE9 Developer Tools > trace, and it was revealing. I noticed something strange. > Accessing the web server by IP, the User-Agent was "Mozilla/5.0", > but by server name User-Agent was "Mozilla/4.0". There are other > header differences too. By IP has the session and cookie info, but > by name does not - aha! The "Accept" header was different also. > > I interpret this to mean that my local IE browser thinks the > intranet web site that I access either by name or by IP is actually > 2 different sites in 2 different security zones. I will try to > adjust my browser security settings and see if that makes any > differences. That sounds plausible. If IE changes its cookie policy based upon those zones, then you may have found the issue. I wonder if your local policy whitelists a certain IP range but doesn't use hostnames, which may account for the difference. Time to ask your webapp software vendor to fix their web application so it can be used without cookies ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUkgZyAAoJEBzwKT+lPKRYiw0QAIVq/Y8aO6JkXM0RQ4d2dWLX 4TDwVF0XI07uVa1QcvkgYxqdvd6pA4yOeZVbqDTv72gGG5gPnKVkqPTCp0lmoZ3m SVxQ0fwSoJOFkzTVo8LMj/LtNYpMbgGr95S4uU7yEU9NvREYggEbD0npxVWt605Q Z+WBvLoSCdmimEQFagCQDiqbx+daosd+Af+WUbP3DrKjT5aLj31CEp3hWzvjas3s eYANOMe0bwf3s5oV1zcRHJLF9cO/mnFFn4ZTW8T9MFUJyYqgQg8rX7Kl5mynpiGt SNOO3RF3IvEzosjMri0FKqrIvLL5TFt7cYvHKTWI0MH3eJERvAnV7HLFebfgaSVv peBxNcNHTr0QLzmKbvM6ykF01xDfqxsBbOXz7CXb4XkHfj7JdoMSa/SuEWQIIc7X vM5+Z4ObVF491VIq7AZBNLh/BwPVT8f5ot0QiFS234FeulfSqRH2rbDjHQhwP4Z0 bpVsmTyY9v2dJdmUZubTBOXgmKgyFSWInIEIEX6i7wQmJLeIU9fNflzg9/iqxxeb WQtYu74SfP3MS79Fy6R/p1v4GxRIpSEIuE2Ovchnb9J3DXLkMKO03xcgu8IoupI9 OjHqjC6CnIV1XGS/cJL96bdAuPYvv3pvPloeT1u+gQ+3KdAf0/XJxBNPSFBOQZJ7 p7LIG+jYWMtX0x7pMWai =KlDA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 ssl by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Duncan, On 12/17/14 12:32 PM, Lyallex wrote: > Yea I thought of this, the problem is I currently have a user area > that requires a login and all this is currently configured in > web.xml and I'm not sure how all this will fit together. I'll try a > few things out and see what happens. You can have multiple, overlapping security-constraints. One of them (which covers the whole site) will require HTTPS, the other (existing one) will require authentication and authorization, but only for certain (again, existing) URL patterns. Should be no problem. - -chris > On 17 December 2014 at 17:20, Mark Thomas > wrote: >> On 17/12/2014 17:10, Lyallex wrote: >>> Tomcat 7.0.42 jdk1.7.0_51 Ubuntu 12.04/CentOS dev/deploy >>> >>> I have been reading more and more about Google and the like >>> prioritising sites that employ https/ssl by default. Currently >>> my site does not use https but delegates payment to a secure >>> payment provider who does, thusly I have avoided going through >>> the pain of certification etc, now it appears I have little >>> option but to implement https site wide. I have managed to get >>> a keystore going and have configured tomcat to serve a self >>> signed certificate when accessing the site by https (default >>> port 443) >>> >>> so http://localhost accesses the home page and >>> https://localhost pops up a warning in Firefox regarding an >>> unknown certification authority. This is all good and I'm >>> pretty sure I understand so far. >>> >>> I have noticed that if I type http://www.google.co.uk in to a >>> browser the address is automatically changed (redirected) to >>> https://www.google.co.uk and I would like the same to happen to >>> my site. >>> >>> Here is the question. Is this 'redirection' something I need to >>> configure myself , (can it be done in server.xml for example) >>> or is this something the people I rent my server from need to >>> do at their end. >> >> It depends on exactly how things are set up. >> >> The first thing I would try is adding something like the >> following to your web.xml: >> >> >> Everything >> /* >> >> CONFIDENTIAL >> >> >> If I have remembered my syntax correctly, that should route >> every request to https if it isn't already. >> >> Mark >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUkgWTAAoJEBzwKT+lPKRYVgYP/0MIsch7SiF2bcMqJtDG7Ovn OFSRej7i+6Mjd0efs6h7QKUqAep8C0QKufOFH7Isn2aZa2TYLQXWIKVJtDqbAqz+ 92K/gpWtZ2FGkB/Qg0GNPWNg/em5u/XWJeFjqMPfufZIk/yIZkMByFzDjXiuS/0n rIdadWqzjvkMJcKAfRzO5CuVPcennzovSLB2/ReGA4lYLzc7b81Stxe+6pE0JBg/ XVzu0BFLuBfKHL0KYL/7TFaYQOpbkSc0ROS3UtzNVNyquXMwYjqCDImpcElvnYYZ XX1eMNFnOf6M+sPItHllJiWHzaQYd3vA9axHeE5/F5XiXruYr8V714jRdQH+XCwX FxcalpMw3wbw8OVwFkRZKzlbBhDeWJiurT2vIols5rHjqtrOwDDMrwt7Nzx57VUD 5HTBb+Ghk8lMFfd/VSh6+NjFfqwp5yAvlUhU4PqNrEkjmx150/JBYa9cfVNFwnk7 Wbfb3sWsTzrYPIgw5yOzoI9X3R5gALFBpRqjnhdrJw0wht8s4GNJbpwq4zwQiGto PSyW3mUnMrxarTK4Wq+enRSaQQWgc7BMELdrsH0ixwG8EAA5gCRhfBSV6SVcGAaY tyuNgJv6Pt+C3xQW/BaXOe24mmxuVmjJU0G6A2oFnPiC3J/gbiwPECjFIAR7yEWp 5ZRKipmvLh3vAoJcvvgR =hjT0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat on windows 2012 weirdness
Hi, > -Original Message- > From: Cris Berneburg - US [mailto:cberneb...@caci.com] > Sent: Wednesday, December 17, 2014 8:15 PM > To: 'Tomcat Users List' > Subject: RE: tomcat on windows 2012 weirdness > > Ameer (and Chris) > > I discovered something else. When accessing the internal web site by name, > it does not work right. But when I access the web site by IP address, it > functions correctly! > > > If you are using IE9, it has a very useful utility in its developer tool to > capture network traffic. Few simple steps to capture it: > > Press F12 --> Go to network tab--> start capturing You can save/export the > captured data in an xml file and then can see everything going to-and-fro > between your browser and server. > > > Compare the traffic when you are communicating from localhost, which > you say is working fine, with the traffic when you are accessing from an > outside client. > > Pay special attention to the headers section of the HTTP calls. > > Thanks for your suggestion. I tried the IE9 Developer Tools trace, and it was > revealing. I noticed something strange. Accessing the web server by IP, the > User-Agent was "Mozilla/5.0", but by server name User-Agent was > "Mozilla/4.0". There are other header differences too. By IP has the session > and cookie info, but by name does not - aha! The "Accept" header was > different also. > > I interpret this to mean that my local IE browser thinks the intranet web site > that I access either by name or by IP is actually 2 different sites in 2 > different > security zones. I will try to adjust my browser security settings and see if > that > makes any differences. Just some additional notes about IE (I don't know if they are applicable to your situation): - IE displays "intranet sites" in "Compatibility mode" by default (that is, IE7 mode). This is why I always add the following HTTP header to websites: X-UA-Compatible: IE=edge This will ensure IE always uses the latest document mode/level. Note that with this header IE's browser mode can still be compatibility view (sending a Mozilla/4.0 MSIE 7.0 User-Agent) although the document mode will be the latest (IE9 on IE9, IE11 on IE11 etc.) The Developer Tools should show the current browser mode and document mode of IE. - In IE on a Windows Server OS, for security reasons the IE enhanced security mode is active which will block some content on websites in the "internet" security zone (while for intranet sites it will use a lower security level). This mode can be enabled or disabled in the Server Manager. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat on windows 2012 weirdness
Chris >>> When emitting a URL onto a page for a client, the application needs to run >>> the URL through a call to HttpServletResponse.encodeURL(String) or >>> HttpServletResponse.encodeRedirectURL(String). These methods will add the >>> ";jsessionid=[id]" path parameter to the URL when the client does not >>> support cookies. In this way, session-tracking will still work. You are "almost certainly" correct about the sessions and cookies. :-) I tried another experiment. I logged into the app to get to the main page and obtain a session. The images did not load. FYI, I checked the links and they do *not* append ";jsessionid=[id]". Then, I went to the address bar and requested one of the images that failed BUT appended ";jsessionid=[id]". (I obtained the active session ID from a Tomcat log file.) The image loaded! >>>If the application isn't doing this for *every URL in the whole >>>application*, then sessions can be dropped and the user will have to >>>re-authenticate. If this is the case, you only have two options: >>> 1. Re-enable cookies on your browser 2. Review the application and >>>fix every instance of a URL on a page (it's a huge job) So the web application is *not* written correctly to handle when the client does not support cookies. That is, it does not call HttpServletResponse .encodeURL or .encodeRedirectURL. And wow, rewriting would be "a huge job". :-) -- Cris Berneburg, Lead Software Engineer CACI, IRMA Project, 703-679-5313 -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, December 12, 2014 2:36 PM To: Tomcat Users List Subject: Re: tomcat on windows 2012 weirdness -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 12/12/14 2:18 PM, Cris Berneburg - US wrote: > Hi Chris > > Thanks for your replies. I am somewhat new to Tomcat, only been using > it for 1 year, so some of the technical details are new to me. > >> Is it possible that you are not using URL-based session ids, and that >> your browser has cookies disabled via a policy? > > I will need to check URL-based session ids. How do I check? If your browser has cookies disabled, then all the links on the web pages in this web application should have a ";jsessionid=[id]" path parameter added to them. See below. > Also, my browser does not have cookies disabled. This is almost certainly the issue. If your browser does not support cookies (Tomcat knows if you support cookies if you send a JSESSIONID cookie, but it can't tell if you send nothing), then the web application must fall-back to using URL-based session-tracking. Unfortunately, this isn't entirely auto-magical: the web application needs to support it properly. Most 3rd-party web applications should already be doing things properly, but if you have an in-house application, it may not be written properly. When emitting a URL onto a page for a client, the application needs to run the URL through a call to HttpServletResponse.encodeURL(String) or HttpServletResponse.encodeRedirectURL(String). These methods will add the ";jsessionid=[id]" path parameter to the URL when the client does not support cookies. In this way, session-tracking will still work. If the application isn't doing this for *every URL in the whole application*, then sessions can be dropped and the user will have to re-authenticate. If this is the case, you only have two options: 1. Re-enable cookies on your browser 2. Review the application and fix every instance of a URL on a page (it's a huge job) >> Is the browser or the server (or both) on Windows 2012? > > The server is on Win 2012. It works OK when both the browser and > server are the same 2012 VM. I don't know if it works when both client > and server are both Win 2012 but different machines. I will be able to > check that soon. It does not work with different client OS version and > box than the server, but that may simply be coincidence. It may be a cookie policy: if localhost is trusted, the cookie policy may change. >> Try using a protocol sniffer to see if the browser is sending a >> session id to the server, and if the server is responding with a >> session id either before or after login. > > Wow, that sounds intimidating - never done that before. :-) It's worth learning how to do. I think there's a plug-in for MSIE called IEHeaders (or something similar). Install that and you can watch the conversation between client and server -- even when TLS is being used. Hope that helps, - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Thursday, December 11, > 2014 1:35 PM To: Tomcat Users List Subject: Re: tomcat on windows > 2012 weirdness > > Cris, > > On 12/11/14 12:41 PM, Christopher Schultz wrote: >> Cris, > >> On 12/11/14 11:28 AM, Cris Berneburg - US wrote: >>> I'm having trouble with my JSP web app using Tomcat 6 and 7 on >>> Windows Server 2012. > >>
RE: tomcat on windows 2012 weirdness
Ameer (and Chris) I discovered something else. When accessing the internal web site by name, it does not work right. But when I access the web site by IP address, it functions correctly! > If you are using IE9, it has a very useful utility in its developer tool to > capture network traffic. Few simple steps to capture it: > Press F12 --> Go to network tab--> start capturing You can save/export the > captured data in an xml file and then can see everything going to-and-fro > between your browser and server. > Compare the traffic when you are communicating from localhost, which you say > is working fine, with the traffic when you are accessing from an outside > client. > Pay special attention to the headers section of the HTTP calls. Thanks for your suggestion. I tried the IE9 Developer Tools trace, and it was revealing. I noticed something strange. Accessing the web server by IP, the User-Agent was "Mozilla/5.0", but by server name User-Agent was "Mozilla/4.0". There are other header differences too. By IP has the session and cookie info, but by name does not - aha! The "Accept" header was different also. I interpret this to mean that my local IE browser thinks the intranet web site that I access either by name or by IP is actually 2 different sites in 2 different security zones. I will try to adjust my browser security settings and see if that makes any differences. -- Cris Berneburg, Lead Software Engineer CACI, IRMA Project, 703-679-5313 -Original Message- From: Ameer Mawia [mailto:ameer.ma...@gmail.com] Sent: Friday, December 12, 2014 3:12 PM To: Tomcat Users List Subject: Re: tomcat on windows 2012 weirdness On Sat, Dec 13, 2014 at 1:06 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Cris, > > On 12/12/14 2:18 PM, Cris Berneburg - US wrote: > > Hi Chris > > > > Thanks for your replies. I am somewhat new to Tomcat, only been > > using it for 1 year, so some of the technical details are new to me. > > > >> Is it possible that you are not using URL-based session ids, and > >> that your browser has cookies disabled via a policy? > > > > I will need to check URL-based session ids. How do I check? > > If your browser has cookies disabled, then all the links on the web > pages in this web application should have a ";jsessionid=[id]" path > parameter added to them. See below. > > > Also, my browser does not have cookies disabled. > > This is almost certainly the issue. > > Chris, I think he meant cookies are already enabled on his browser. > If your browser does not support cookies (Tomcat knows if you support > cookies if you send a JSESSIONID cookie, but it can't tell if you send > nothing), then the web application must fall-back to using URL-based > session-tracking. > > Unfortunately, this isn't entirely auto-magical: the web application > needs to support it properly. Most 3rd-party web applications should > already be doing things properly, but if you have an in-house > application, it may not be written properly. > > When emitting a URL onto a page for a client, the application needs to > run the URL through a call to HttpServletResponse.encodeURL(String) or > HttpServletResponse.encodeRedirectURL(String). These methods will add > the ";jsessionid=[id]" path parameter to the URL when the client does > not support cookies. In this way, session-tracking will still work. > > If the application isn't doing this for *every URL in the whole > application*, then sessions can be dropped and the user will have to > re-authenticate. If this is the case, you only have two options: > > 1. Re-enable cookies on your browser > 2. Review the application and fix every instance of a URL on a page > (it's a huge job) > > >> Is the browser or the server (or both) on Windows 2012? > > > > The server is on Win 2012. It works OK when both the browser and > > server are the same 2012 VM. I don't know if it works when both > > client and server are both Win 2012 but different machines. I will > > be able to check that soon. It does not work with different client > > OS version and box than the server, but that may simply be > > coincidence. > > It may be a cookie policy: if localhost is trusted, the cookie policy > may change. > > >> Try using a protocol sniffer to see if the browser is sending a > >> session id to the server, and if the server is responding with a > >> session id either before or after login. > > > > Wow, that sounds intimidating - never done that before. :-) > > It's worth learning how to do. I think there's a plug-in for MSIE > called IEHeaders (or something similar). Install that and you can > watch the conversation between client and server -- even when TLS is > being used. > > If you are using IE9, it has a very useful utility in its developer tool to capture network traffic. Few simple steps to capture it: Press F12 --> Go to network tab--> start capturing Y
RE: tomcat on windows 2012 weirdness
Chris Thanks again for your replies. Meh, sorry for the double-negative about the cookies. :-) One thing I learned by trial and error is that accessing the internal web site by name behaves wrongly, but accessing it by IP behaves rightly! Also, I must be wrong about the cookies being enabled/disabled anyway. I did the IE9 trace Ameer suggested, and it was revealing. It appears the cookies are conditional depending on how the server is accessed. Will follow up in another message. -- Cris Berneburg, Lead Software Engineer CACI, IRMA Project, 703-679-5313 -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, December 12, 2014 3:15 PM To: Tomcat Users List Subject: Re: tomcat on windows 2012 weirdness -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ameer, On 12/12/14 3:11 PM, Ameer Mawia wrote: > On Sat, Dec 13, 2014 at 1:06 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Cris, > > On 12/12/14 2:18 PM, Cris Berneburg - US wrote: Hi Chris Thanks for your replies. I am somewhat new to Tomcat, only been using it for 1 year, so some of the technical details are new to me. > Is it possible that you are not using URL-based session ids, and > that your browser has cookies disabled via a policy? I will need to check URL-based session ids. How do I check? > > If your browser has cookies disabled, then all the links on the web > pages in this web application should have a ";jsessionid=[id]" > path parameter added to them. See below. > Also, my browser does not have cookies disabled. > > This is almost certainly the issue. > > >> Chris, I think he meant cookies are already enabled on his browser. Ah! A double-negative. I read too quickly. Well, the protocol analyzer will certainly help inform the conversation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUi0zKAAoJEBzwKT+lPKRYZHAQAJYqjchuvYXOuYQN2PmjAbly dnlmXiOJIeaPVCaVtFy2oBxhxP0KaAZHFUdofF2n9Fx2s5EIL5fxexIp0wkQmmuE PORs1Wm5Iz0ArOVCXcP3lBgQFYB/TRY0ryo/2MTQE7Eto77frBGL6gduqiHeelJn vfJ9DF1IujxWadGVzhF6277wkANrL/RBJBr23ly/dBGmZ09mzGMtGWbLdXPxN6rv IimC1K8/r4RKbz8qYRib1CCx2Rmn5xfxw5aAp0I71xyUdBygSH6DiZmzLKDalCnV OqX6ujD5TlFO7x56I7/C+BdohZUXopTKQwVFnvbgbTsfBwZ9qNQCFtcI6QauYJWK B9Q8Jo5uZ+7kSE/5U9EY6G6vZUKGBi2iqc13CWMrpMNOavjO9vIc823WBjkfPVIP cd8WQgwjQaHLooGeHKxkPZDiUKXsIK4/aGLs38V2Oe3NvTnZLuWqAcXyuwke2/sP Yav+Yp9F7QKIZnlJWSjIM3Nk4DZjg4P2p3pi/N+k3ko0g/4L9P4tBirE2BwzT/Yu CpFLF//Io0xTeSk5BbB2ghTBY5dzZOZNA4oNhTAXvgvrLaENYKb2vwRu8ArACVR+ bBnFGgkEC+vl26KgcZVJEfrj+9Q+Q9eMAs7VkAIikfizZYogYdXBKNXdj+Y72LM2 /Cup5W8jGgaXJnzLCm8k =lmci -END PGP SIGNATURE-
Re: Tomcat 7 ssl by default
Yea I thought of this, the problem is I currently have a user area that requires a login and all this is currently configured in web.xml and I'm not sure how all this will fit together. I'll try a few things out and see what happens. Thanks for taking the time to respond Duncan On 17 December 2014 at 17:20, Mark Thomas wrote: > On 17/12/2014 17:10, Lyallex wrote: >> Tomcat 7.0.42 >> jdk1.7.0_51 >> Ubuntu 12.04/CentOS dev/deploy >> >> I have been reading more and more about Google and the like >> prioritising sites that employ https/ssl by default. Currently my site >> does not use https but delegates payment to a secure payment provider >> who does, thusly I have avoided going through the pain of >> certification etc, now it appears I have little option but to >> implement https site wide. I have managed to get a keystore going and >> have configured tomcat to serve a self signed certificate when >> accessing the site by https (default port 443) >> >> so http://localhost accesses the home page >> and https://localhost pops up a warning in Firefox regarding an >> unknown certification authority. This is all good and I'm pretty sure >> I understand so far. >> >> I have noticed that if I type http://www.google.co.uk in to a browser >> the address is automatically changed (redirected) to >> https://www.google.co.uk and I would like the same to happen to my >> site. >> >> Here is the question. >> Is this 'redirection' something I need to configure myself , (can it >> be done in server.xml for example) or is this something the people I >> rent my server from need to do at their end. > > It depends on exactly how things are set up. > > The first thing I would try is adding something like the following to > your web.xml: > > > > Everything > /* > > > CONFIDENTIAL > > > > If I have remembered my syntax correctly, that should route every > request to https if it isn't already. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 ssl by default
On 17/12/2014 17:10, Lyallex wrote: > Tomcat 7.0.42 > jdk1.7.0_51 > Ubuntu 12.04/CentOS dev/deploy > > I have been reading more and more about Google and the like > prioritising sites that employ https/ssl by default. Currently my site > does not use https but delegates payment to a secure payment provider > who does, thusly I have avoided going through the pain of > certification etc, now it appears I have little option but to > implement https site wide. I have managed to get a keystore going and > have configured tomcat to serve a self signed certificate when > accessing the site by https (default port 443) > > so http://localhost accesses the home page > and https://localhost pops up a warning in Firefox regarding an > unknown certification authority. This is all good and I'm pretty sure > I understand so far. > > I have noticed that if I type http://www.google.co.uk in to a browser > the address is automatically changed (redirected) to > https://www.google.co.uk and I would like the same to happen to my > site. > > Here is the question. > Is this 'redirection' something I need to configure myself , (can it > be done in server.xml for example) or is this something the people I > rent my server from need to do at their end. It depends on exactly how things are set up. The first thing I would try is adding something like the following to your web.xml: Everything /* CONFIDENTIAL If I have remembered my syntax correctly, that should route every request to https if it isn't already. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 ssl by default
Tomcat 7.0.42 jdk1.7.0_51 Ubuntu 12.04/CentOS dev/deploy I have been reading more and more about Google and the like prioritising sites that employ https/ssl by default. Currently my site does not use https but delegates payment to a secure payment provider who does, thusly I have avoided going through the pain of certification etc, now it appears I have little option but to implement https site wide. I have managed to get a keystore going and have configured tomcat to serve a self signed certificate when accessing the site by https (default port 443) so http://localhost accesses the home page and https://localhost pops up a warning in Firefox regarding an unknown certification authority. This is all good and I'm pretty sure I understand so far. I have noticed that if I type http://www.google.co.uk in to a browser the address is automatically changed (redirected) to https://www.google.co.uk and I would like the same to happen to my site. Here is the question. Is this 'redirection' something I need to configure myself , (can it be done in server.xml for example) or is this something the people I rent my server from need to do at their end. TIA Duncan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat cluster with static membership
On 2014-12-09 19:01, Mark Eggers wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/9/2014 9:48 AM, Daniel Mikusa wrote:
On Tue, Dec 9, 2014 at 9:16 AM, Théo Chamley
wrote:
On 2014-12-08 21:22, Ameer Mawia wrote:
Hi Theo,
Since you are using static membership and NOT
dynamic(multi-cast) which auto-detect members, my current
understanding says that you will have to add entry of all the
members of your cluster in each of nodes server.xml. Example:
My cluster has two nodes. So to configure these I had add these
two members entries in both node's server.xml(since running on
the same machine, they have varying port with same ip):
Regards, Ameer Mawia
On Mon, Dec 8, 2014 at 8:26 PM, Théo Chamley
wrote:
Hello,
I am trying to setup a simple Tomcat cluster with static
membership. I can't use multicast because I am on a
virtualization environment that does not allow it.
Debian 7 Tomcat 8.0.14 Oracle JVM 1.8.0_25
Both Tomcat are ok on their own, but I can't seem to make the
clustering work: the sessions are not replicated from one to
another. Following the official documentation, I wrote this
configuration :
[...]
Note: I changed the host and uniqId on the
StaticMembershipInterceptor on the other Tomcat.
This is not a network problem as I can telnet into the 4110
port from one server to another. Also, by running a tcpdump,
I can't see any trafic between the two servers.
The Tomcats seem to be doing something, because I have the
following in my catalina.out:
** 08-Dec-2014 15:38:15.309 INFO [main]
org.apache.catalina.ha.tcp. SimpleTcpCluster.startInternal
Cluster is about to start 08-Dec-2014 15:38:15.312 INFO
[main] org.apache.catalina.tribes.
transport.ReceiverBase.bind Receiver Server Socket bound
to:/0.0.0.0:4110 08-Dec-2014 15:38:15.328 INFO [Thread-5]
org.apache.catalina.ha.tcp. SimpleTcpCluster.memberAdded
Replication member
added:org.apache.catalina.tribes.membership. StaticMember[t
cp://my.server.1:4110,my.server.1,4110, alive=0,
securePort=-1, UDP Port=-1, id={1 2 3 4 5 6 7 8 9 10 11 12 13
14 15 0 }, payload={}, command={}, domain={115 116 97 103 105
110 103 45 99 ...(15)}, ] 08-Dec-2014 15:38:15.330 INFO
[main] org.apache.catalina.tribes.
membership.McastServiceImpl.setupSocket Setting cluster mcast
soTimeout to 500 08-Dec-2014 15:38:15.332 INFO [main]
org.apache.catalina.tribes.
membership.McastServiceImpl.waitForMembers Sleeping for 1000
milliseconds to establish cluster membership, sta rt level:4
08-Dec-2014 15:38:16.155 INFO [Membership-MemberAdded.]
org.apache.catalina.ha.tcp.SimpleTcpCluster.memberAdded
Replication member
added:org.apache.catalina.tribes.membership
.MemberImpl[tcp://{0, 0, 0, 0}:4110,{0, 0, 0, 0},4110,
alive=1277686, securePort=-1, UDP Port=-1, id={-22 -45 110
-29 21 -22 75 95 -103 86 95 -119 15 48 -17 -27 }, payload={}
, command={}, domain={}, ] 08-Dec-2014 15:38:16.259 INFO
[Tribes-Task-Receiver-1]
org.apache.catalina.tribes.io.BufferPool.getBufferPool
Created a buffer pool with max size:104857600 bytes of type:
org.apache.catalina.tribes.io. BufferPool15Impl 08-Dec-2014
15:38:16.332 INFO [main] org.apache.catalina.tribes.
membership.McastServiceImpl.waitForMembers Done sleeping,
membership established, start level:4 08-Dec-2014
15:38:16.335 INFO [main] org.apache.catalina.tribes.
membership.McastServiceImpl.waitForMembers Sleeping for 1000
milliseconds to establish cluster membership, start level:8
08-Dec-2014 15:38:17.335 INFO [main]
org.apache.catalina.tribes.
membership.McastServiceImpl.waitForMembers Done sleeping,
membership established, start level:8 **
Could someone, please, help me finding what I am doing
wrong?
Thanks,
Théo C.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
users-h...@tomcat.apache.org
Hello,
Thank you for your answer. Indeed, I need both nodes in the
Interceptor, but something else is wrong. I missed it the first
time, but the official documentation mentions that the
TcpFailureDetector must be above the
StaticMembershipInterceptor. I suspect that it is also true of
the other Interceptors, but I'm not sure.
Here is my conf right now. I made some progress: I now have
trafic between the two servers on the port 4110. Its regularity
makes my think it's a heartbeat. However, the two Tomcat still do
not share any sessions.
[...]
Is there some way for me to debug what is happening?
Have you turned on debug level logging? Maybe try packages like
"org.apache.catalina.ha" and "org.apache.catalina.tribes". From
what I remember, it spits out a lot of information.
Dan
- From my Tomcat 7 cluster experiment (check the documentation to see
if
things have changed in Tomcat 8):
# logging.properties
# all one line
# note 5cluster.org.apache.juli.FileHandler at the end
#
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.j
Re: About scanAllDirectories,JarScanner and expanded JAR
On 17/12/2014 10:38, Nan Ge wrote: > On Wed, Dec 17, 2014 at 4:07 PM, Mark Thomas wrote: >> >> On 17/12/2014 01:56, Nan Ge wrote: >> >>> And the directory structure looks like this: >>> F:\PROJECTS\MYAPP >>> ├─src >>> │ └─main >>> │ ├─java >>> │ └─webapp >>> │ └─WEB-INF >>> │ └─lib >>> └─target >>> └─myapp //this is my web application context root >>> ├─META-INF >>> └─WEB-INF >>> ├─classes >>> └─lib >>> └─mybiz //this folder contains classes extracted >>> from mybiz.jar >>> ├─META-INF >>> └─myapp >>> └─biz >> >> WEB-INF/lib is only ever scanned for JARs. Everything else is ignored. >> >> classes belong in WEB-INF/classes without the top-level "mybiz" directory. >> >> Mark > > > Yes, classes belong in WEB-INF/classes without any top-level > non-package-name directory is the standard deployment structure defined by > the servlet spec. > > What I really want to know is what the consequence will be if we set > scanAllDirectories=true The consequences will be as specified in the documentation. > and the Jar Scanner assumes the folder to be an expanded JAR file(if the > META-INF sub-directory exists) ? It won't since "the folder" in this case is WEB-INF/lib which is not on the class path. > Could the classes within the expanded > JAR folder > be loaded by the web application class loader? Which part of "WEB-INF/lib is only ever scanned for JARs. Everything else is ignored." did you not understand? >> >> I see the logic behind the guess but it is wrong. This option won't work for > either of those directories. >> > > And which directories/classpath the document indicates when it saying "If > true, any directories found on the classpath will be checked to see if they > are expanded JAR files" , if it "won't work for either of those > directories"? As per the docs, scanAllDirectories applies to directories found on the class path not to WEB-INF/lib since it is not on the class path. (WEB-INF/lib/*.jar is on the class path and that is not a directory). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About scanAllDirectories,JarScanner and expanded JAR
On Wed, Dec 17, 2014 at 4:07 PM, Mark Thomas wrote: > > On 17/12/2014 01:56, Nan Ge wrote: > > > And the directory structure looks like this: > > F:\PROJECTS\MYAPP > > ├─src > > │ └─main > > │ ├─java > > │ └─webapp > > │ └─WEB-INF > > │ └─lib > > └─target > > └─myapp //this is my web application context root > > ├─META-INF > > └─WEB-INF > > ├─classes > > └─lib > > └─mybiz //this folder contains classes extracted > > from mybiz.jar > > ├─META-INF > > └─myapp > > └─biz > > WEB-INF/lib is only ever scanned for JARs. Everything else is ignored. > > classes belong in WEB-INF/classes without the top-level "mybiz" directory. > > Mark Yes, classes belong in WEB-INF/classes without any top-level non-package-name directory is the standard deployment structure defined by the servlet spec. What I really want to know is what the consequence will be if we set scanAllDirectories=true and the Jar Scanner assumes the folder to be an expanded JAR file(if the META-INF sub-directory exists) ? Could the classes within the expanded JAR folder be loaded by the web application class loader? > >I see the logic behind the guess but it is wrong. This option won't work for either of those directories. > And which directories/classpath the document indicates when it saying "If true, any directories found on the classpath will be checked to see if they are expanded JAR files" , if it "won't work for either of those directories"? Regards, Nan
Re: About scanAllDirectories,JarScanner and expanded JAR
On 17/12/2014 01:56, Nan Ge wrote: > And the directory structure looks like this: > F:\PROJECTS\MYAPP > ├─src > │ └─main > │ ├─java > │ └─webapp > │ └─WEB-INF > │ └─lib > └─target > └─myapp //this is my web application context root > ├─META-INF > └─WEB-INF > ├─classes > └─lib > └─mybiz //this folder contains classes extracted > from mybiz.jar > ├─META-INF > └─myapp > └─biz WEB-INF/lib is only ever scanned for JARs. Everything else is ignored. classes belong in WEB-INF/classes without the top-level "mybiz" directory. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About scanAllDirectories,JarScanner and expanded JAR
On 17/12/2014 02:08, Nan Ge wrote: > On Wed, Dec 17, 2014 at 2:43 AM, Mark Thomas wrote: >> >> On 16/12/2014 18:00, Christopher Schultz wrote: >>> Nan, >>> >>> On 12/16/14 5:37 AM, Nan Ge wrote: I'm using Tomcat8. I'm not quite understand about the description of 'scanAllDirectories' attribute of the component. The doc says if this attribute is set true, 'any directories found on the classpath will be checked to see if they are expanded JAR files. ... Tomcat determines if a directory is an expanded JAR file by looking for a META-INF sub-directory'. >>> Does it mean that we could extract the content of a JAR file(including the META-INF dir) to a folder under /WEB-INF/lib or /WEB-INF/classes(with unpackWAR=true) of my web application, and Tomcat will load associated classes, which were originally in the JAR, from this folder? >>> >>> I haven't tried, but I would guess that it would only work under >>> WEB-INF/lib and not WEB-INF/classes since WEB-INF/classes isn't >>> expected to ever contain JAR files (at least not ones that are >>> automatically added to the classpath, like .jar files in WEB-INF/lib >> are). >> >> I see the logic behind the guess but it is wrong. This option won't work >> for either of those directories. >> ? >> Mark >> >> Thanks Mark! > > Then how to make this 'scanAllDirectories' attribute work, The attribute does work. There is nothing wrong with it. > or do you mean it has been discarded in Tomcat8.0 ? I mean nothing of the sort. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
