Specific class loading in my webapp
Hello all, I search a means to force my webapp when is deploy in tomcat, to take several jars/classes in located in a specific directory. For example when my webapp start, it load jars into /var/lib/my-repository/ Is it possible to do this directly with a classloader in my webapp, and also dynamically reload classes. Or it's only tomcat configuration ? Thank you very much and best regards Adrien
AW: AW: grab hostname from tomcat manager
-Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 2. April 2014 22:33 An: Tomcat Users List Betreff: Re: AW: grab hostname from tomcat manager -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bjorn, On 4/2/14, 10:54 AM, bjoern.bec...@easycash.de wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 2. April 2014 16:35 An: Tomcat Users List Betreff: Re: grab hostname from tomcat manager bjoern.bec...@easycash.de wrote: Hello, I need to grab the hostname from the tomcat manager somehow. Unfortunately this URL manager/text/serverinfo doesn't contain the hostname. Is there any other smart way to receive the hostname via tomcat manager app? For give me for asking, but how do you access the tomcat manager if you do not know the hostname ? Good question :). But I got a good reason for it. I got two servers with several tomcat instances. In front of them is a loadbalancer with is configured to do a failover. -LB- / \ Server1:8081 Server2:8081 I need to write a shell script to sync a specific directory and for each tomcat instance I need to know on which one the loadbalancer is targeting at the moment. How will you check to see which one the lb is targeting? That's the question. If tomcat 8081 on server 1 is down, the loadbalancer will point to server 2 tomcat 8081. I can find it out through the loadbalancer address only. You should probably set a jvmRoute in your Engine in server.xml. That way, you can detect which back-end server you are getting just by looking at the JSESSIONID cookie. That's the answer. When jvmroute is define I easily can receive the jsession id with wget: wget -q -O - --no-cache --keep-session-cookies --no-check-certificate --save-cookies cookies.txt https://loadbalanceraddress:8081/manager --user=user--password=secure 1/dev/null perfect! Thanks a lot! Björn - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPHPuAAoJEBzwKT+lPKRYW+oQAKr/BQOhCwBxlA+0cboIWdoO HLQw8czwuYVqxag9cFiy7XiAUGmnph3pYfZTj6YcYXKDVBEeCuWEVPDFsSuRQG3u +I9UnWFnoFn8OCWJyv2RKKBfkZ3UhjJom3JmLnHxnWb4KbU9yz/ep5xNpJ43WY3x VxiPlkdksIKTiwycc6itM+5/URoHn5LzMSAdzb2ZFVhx/VlaubAfqaAo6fIVylTj TZ0JdZR9QNvL+KO+QPUN5c9j2unVk08oc1feNSyDOdWrs0Fg4e5i6qjORxroA17L 1uEZhnivHL8wvUt89F+oQ+1rqBIff+c242vdvDE7STJK4vUJfSk2JLPIvu/fApfl NhTgCCM8J7XOIUgCT556RHjioUhCumdzL24PUiIs30DSMYB2/5pC+jarF4+3iXI5 8tAeZR+vVaTaszKYoWjA37dV3WIC+06Us5v2hmmVcuyVxN+IE/hqrxpBkSORcbO4 5PpXJThPHQPvHMwJCywwIxaEDfLuxcWMXD4TJl5cogePt/BRA3p+9xafbuGJvEkN gaUDSNLXGMTd9iKUHdjH5g5arEPs0tIy5EJVpIcNk1X2QS0nfzH4P7TjrqNj432c fn3NPUUKn1QdIW6enyc6rgHnF+JHPFCETCtkmbX8lNfqr7rtorpmFXphvrFqcAFa B43OfQbSyuHsrkfVSoEx =RiHw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: grab hostname from tomcat manager
bjoern.bec...@easycash.de wrote: -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 2. April 2014 22:33 An: Tomcat Users List Betreff: Re: AW: grab hostname from tomcat manager -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bjorn, On 4/2/14, 10:54 AM, bjoern.bec...@easycash.de wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 2. April 2014 16:35 An: Tomcat Users List Betreff: Re: grab hostname from tomcat manager bjoern.bec...@easycash.de wrote: Hello, I need to grab the hostname from the tomcat manager somehow. Unfortunately this URL manager/text/serverinfo doesn't contain the hostname. Is there any other smart way to receive the hostname via tomcat manager app? For give me for asking, but how do you access the tomcat manager if you do not know the hostname ? Good question :). But I got a good reason for it. I got two servers with several tomcat instances. In front of them is a loadbalancer with is configured to do a failover. -LB- / \ Server1:8081 Server2:8081 I need to write a shell script to sync a specific directory and for each tomcat instance I need to know on which one the loadbalancer is targeting at the moment. How will you check to see which one the lb is targeting? That's the question. If tomcat 8081 on server 1 is down, the loadbalancer will point to server 2 tomcat 8081. I can find it out through the loadbalancer address only. You should probably set a jvmRoute in your Engine in server.xml. That way, you can detect which back-end server you are getting just by looking at the JSESSIONID cookie. That's the answer. When jvmroute is define I easily can receive the jsession id with wget: wget -q -O - --no-cache --keep-session-cookies --no-check-certificate --save-cookies cookies.txt https://loadbalanceraddress:8081/manager --user=user--password=secure 1/dev/null perfect! Alternatively, I suppose that you could just create a small JSP (or even HTML, but then host-specific) page in each host, which returns the real hostname. You should probably be careful however : in your rsync scenario above, is there any guarantee that between the time you ask for the hostname (in whatever way), and the time at which you do your rsync, the targeted host will still be the same ? Remember that if things /can/ happen, they /do/ happen. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specific class loading in my webapp
On Apr 3, 2014, at 3:53 AM, Adrien RUFFIE a.ruf...@e-deal.com wrote: Hello all, What version of Tomcat are you using? I search a means to force my webapp when is deploy in tomcat, to take several jars/classes in located in a specific directory. For example when my webapp start, it load jars into /var/lib/my-repository/ Possibly VirtualWebappLoader? http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation Is it possible to do this directly with a classloader in my webapp, and also dynamically reload classes. Or it's only tomcat configuration ? What do you mean by dynamically reload classes? Do you mean reload the context? Dan Thank you very much and best regards Adrien Т�ХF�V�7V'67�R�R���âW6W'2�V�7V'67�TF��6B�6�R��pФf�FF�F����6����G2�R���âW6W'2ֆV�F��6B�6�R��pР - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between-ip-addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Regards, Jessica smime.p7s Description: S/MIME cryptographic signature
Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between-ip-addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do ping localhost. It should tell you what it understands by localhost. Copy and paste the result here : Note : I would be really surprised if mod_jk did not parse this correctly. More likely is, that localhost on that system, is aliased to some invalid target IP address. IP address 0.0.0.0, for a listen socket, means any configured IP address of this computer. But for a client socket, connecting to 0.0.0.0 does not really make sense. In your case, the AJP connector in Tomcat is the server, and it listens to 0.0.0.0:8009, and that makes sense as all interfaces, port 8009. And mod_jk/isapi is the client in this case. It is trying to connect to localhost, which should be 127.0.0.1, under IPv4. That connection would be seen and accepted by the AJP listening socket. But mod_jk is probably trying to connect to something else, and failing. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014 15:36 An: Tomcat Users List Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between- ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do ping localhost. It should tell you what it understands by localhost. Copy and paste the result here : ping localhost Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms smime.p7s Description: S/MIME cryptographic signature
Re: tomcat randomly undeploys and redeploys the applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 4/2/14, 5:20 PM, Mark Eggers wrote: Chris, On 4/2/2014 1:54 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 4/2/14, 4:30 PM, Mark Eggers wrote: Chris, On 4/2/2014 1:05 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 4/2/14, 8:21 AM, Caldarale, Charles R wrote: From: Elias Kopsiaftis [mailto:yemi...@gmail.com] Subject: tomcat randomly undeploys and redeploys the applications I deploy the application, then in the log file catalina.out i get many messages from WebappClassLoader clearReferencesThreads saying threads appear to have started but have failed to stop This is an indication that your webapp is not managing its threads properly. then finally, Ill get a message from HostConfig checkResources that says its undeploying the context, and then it redeploys. This is sometimes caused by incorrect timestamps on the bits of the webapp that Tomcat monitors, or an incorrect clock setting on the system Tomcat is running on. The mismatch makes it appear that the webapp is being updated continuously. I've found that in development, a single update can cause Tomcat to go into a loop of redeployments, re-deploying my web application every few seconds or so. If I let it go, it does finally stop reloading and settle down. Can you describe your development environment a little bit, and any thoughts as to what might trigger this loop of redeployments? I use Eclipse for development, but our real build process is ant-based. We have some watched resources configured outside the default (stuff like Struts config files, etc.). Ah, makes sense. When I do a build while Tomcat is running, usually I get one webapp reload, but sometimes I get a series of reloads. It usually gets so irritating (our webapp takes about 10 seconds to reload) that I just kill Tomcat and immediately restart it. It starts up once and all is well after that. Yep, and in the process more files are copied about, and that triggers another reload. Fun, fun. No, the deployment update takes like one or two seconds. It's usually something like copying less than 10 class files or whatever. It's nearly instantaneous. Whatever happens, it's not because I'm updating files during the reload. I could understand that situation. What I observe is that I update my application, I wait maybe 10 seconds, and then Tomcat reloads my application multiple times before I just kill it. I've not seen this, but it could explain some issues some the developers I support are seeing. It definitely happens, and I never remember to enable the DEBUG logging to find out what resource it thinks has been updated until after it happens, at which point I just don't care. Perhaps I should enable it right now :) - -chris I've managed to make this happen in my environment now (NetBeans 7.4, Maven 3.2.1, Tomcat 7.0.42 - all will be upgraded soon). I just needed an application that takes a bit longer to load. I only managed to trigger two reloads, so it's not much of an issue. Maybe look at adding the backgroundProcessorDelay attribute to the context? I don't know what would happen if the context got a string of reload requests within the delay interval. Would it queue them up one after the other, or would it just execute one? I think it's more important to see what file(s) Tomcat thinks is(are) being updated. I wonder if it's the same file, or if there's some weird timestamp issue happening. Perhaps there is even some kind of edge case where a resource's last-modified date isn't being updated properly. In most cases, Tomcat reloads my application a single time, as expected. These reload-storms are fairly rare. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPYcLAAoJEBzwKT+lPKRYf/gQAKhUNIp0yIP24g6fctOppPGC 0WbacCWGaJwC9Xbuh/lNqtYRZck2943+rOZwOw4sBfwxox3dlVYGl+NHj0C4NRyW KJmH11v5gO59Di7S4NZeYGlHpbYWSZt/2HiMZAVQ6zElXN5qkSEa5WbjXJJsduSe FHD6RFLST7pvlbOuEj8L/+MldsflYTe7Mu5CykBK52GLZGMAYTFYWqcs6nrsscxc ZWEKAt1QU1barvojnoZjk4pZksihi/QwOmCJ1a+rHWUZPmtzp/9gdTon47WHDcXU NVEQLOHJgtolJI2XYMVXFZPVOEeD80PWdQ+aIUAozOR954odw9RcZRz71EiNAagB YBImgFi0zFNwVKivi4yqKHGex8LPj6qGuDI2Nd48Za4s6gN90fpHwpYFzrq3dnnv ep7Jf1qHNiGc70s//TH8iKZToCkN/N2Sythlv729NEFGdXBkn0Ph8RVhPmxiYiwu WrIXrk875m2241QBubcuaNFnPPmNA2cj0IkHB8QDM+35wUI40sx+vtMvLV3U674O JBATY5Oiq26jj585OAsNJJsNY1y33rkH0tqZNEPTYUfqSW4FUxHe0J6TWf7CMujF sPjQqk1kXawsyNJNeGqKxUqW6LHvo+dX40/FmgAl4llkOCU9DFXxdhZVBg14UQdC OeWlyGTxwovZZEdJJqtO =r81a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: grab hostname from tomcat manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/3/14, 5:14 AM, André Warnier wrote: bjoern.bec...@easycash.de wrote: -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 2. April 2014 22:33 An: Tomcat Users List Betreff: Re: AW: grab hostname from tomcat manager -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bjorn, On 4/2/14, 10:54 AM, bjoern.bec...@easycash.de wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 2. April 2014 16:35 An: Tomcat Users List Betreff: Re: grab hostname from tomcat manager bjoern.bec...@easycash.de wrote: Hello, I need to grab the hostname from the tomcat manager somehow. Unfortunately this URL manager/text/serverinfo doesn't contain the hostname. Is there any other smart way to receive the hostname via tomcat manager app? For give me for asking, but how do you access the tomcat manager if you do not know the hostname ? Good question :). But I got a good reason for it. I got two servers with several tomcat instances. In front of them is a loadbalancer with is configured to do a failover. -LB- / \ Server1:8081 Server2:8081 I need to write a shell script to sync a specific directory and for each tomcat instance I need to know on which one the loadbalancer is targeting at the moment. How will you check to see which one the lb is targeting? That's the question. If tomcat 8081 on server 1 is down, the loadbalancer will point to server 2 tomcat 8081. I can find it out through the loadbalancer address only. You should probably set a jvmRoute in your Engine in server.xml. That way, you can detect which back-end server you are getting just by looking at the JSESSIONID cookie. That's the answer. When jvmroute is define I easily can receive the jsession id with wget: wget -q -O - --no-cache --keep-session-cookies --no-check-certificate --save-cookies cookies.txt https://loadbalanceraddress:8081/manager --user=user--password=secure 1/dev/null perfect! Alternatively, I suppose that you could just create a small JSP (or even HTML, but then host-specific) page in each host, which returns the real hostname. You should probably be careful however : in your rsync scenario above, is there any guarantee that between the time you ask for the hostname (in whatever way), and the time at which you do your rsync, the targeted host will still be the same ? Remember that if things /can/ happen, they /do/ happen. I still don't really grok the use case, here, but if you use a bogus JSESSIONID (like GimmieMyServer.jvmRoute), you can select the backend server if you are using a load balancer that understands what the jvmRoute means (like mod_jk does, for instance). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPYd6AAoJEBzwKT+lPKRYHngQAJ6zTouqqV4riBzgB6peRFTT PxMGOT/yEfWxPnja8ZUeY9XRT6n3N07eg6vyELEOVSBMyXZSeeyef7mOomUPgrZz /ADu7tieCE/bUkW24xrOs4Uklw+1AmeYwheTZ5bztHZRhkGpEqEExQD/E/6lVnQH OpNv1MWIkUumk3f3UeIviibyrv/AAdCxgjukAgFkk2zWTAcLtYgBZ1psS8NpDUO8 ynM0drQuThCpdZmfCjSQWC+V+U7PS2Qc8L5q9xYm6dnilDhUp0YDW0Gf3/zTUudX gBXTkE9XN2AnG6UnP+st//Jrwwjjw8PEL6u6q1fpThSyWRq9A8A8yYHm4O6qYMiW A/YtOHlyGZ7L4E2T+bshz56AInEUEKEVSjdlZH95W17zgOlVqgWuFZAQG59Yow2D U18NEN4PnFOjxwsMY6VdpK3tSL+Tu3EazYt0qfyhV/vguhufOpNjNoZC6hfDyh5C zdcV8kKdogvjhl2zR9yjm+nFOIEH6B+TiQB96/XphX7MBY7DYJFwOkshDPN6dd0w PwSXCbuX9i7WMEYPNmkqK1fgPtqqVdx7Sj586OYThEi3SVNhP2+owx0/OEqhuYey BOm+i2z+FTzS87q20PV7tOsJbh5H5JkHxP6MXNVSY4Yah+XUbYCo9VU8LxbgTmDZ jCNjBmv4hnYMmvZFdzzX =6lZK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specific class loading in my webapp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adrien, On 4/3/14, 3:53 AM, Adrien RUFFIE wrote: I search a means to force my webapp when is deploy in tomcat, to take several jars/classes in located in a specific directory. For example when my webapp start, it load jars into /var/lib/my-repository/ Is it possible to do this directly with a classloader in my webapp, and also dynamically reload classes. Or it's only tomcat configuration ? Thank you very much and best regards You can specify your own Loader[1] under Context. Feel free to write your own ClassLoader, but it has better implement the requirements of a web application ClassLoader. The VirtualWebappClassLoader (as suggested by Daniel) is a special case: it's a ClassLoader that's already been written for you. Before you write your own ClassLoader, try VWCL and ask here if you can't get it to meet your requirements. It's easy to write your own broken ClassLoader. - -chris [1] http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPYgyAAoJEBzwKT+lPKRYUDQQAMOOWZRnxhHgy4C+PxiKs2UI YKHornJLXPeQ4/zPg4ZfO+siFzjpdiDhI7kbO+ms2/oY1NioxpjAOSglTOLYIZCg bX7SX21ubk6jDe1dKcBtc96H6PgxtypQOYIM/rkzVJYWcAAdIrPPutZdSMijdRJq H9xoULEqtffVPTgfX3KP5b8Y56vE89ys06E1/ygckh876DV2kuZUaKXKiSUzI41W tWcroAOS/zaEledBzkGq/bPtqzrYfSvFwEATgX0L+Tm/1lYhXfn/377qr41rGuDV SfPIT6dQWqw4dXBJf25uXJhGxLeLdZs8J50RDgtnLs0mQpzLrx3xkGhyUEXMZAZa mwSDMc+yRKmCc6FNqjhFY8Y1RV31VYgtCo04+9ZFSiZsUp3Y7rQa40co4WnZkZ0c wmDCSzTx26aE1RlT4IEOE/Z5xhfSFTcFJrg3I5xYgOUawZGYbJPVSdOrulp89d66 qahKelULTNV1qoLcj0S2G2t5NZx+JBkw35QJ8LsDo9uRvo+uwlIBqDA+OUbWalfB e2cdNI5S83GR0ZpNnUqa9pdy9vSqm7tsQTgMx5nw9Dup9v6wwwdWnIMULn99OrDf Xs8h/IvXDA42WP49jooVhl8a7dLfv9kubxu8AQ/Q5R0cMZgRR/b0ilzShMxlhPDp No2spC3lLYrWFBL4Rruv =3KZa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
catalina.out anomaly?
Greetings, I am unable to understand how Tomcat v7.0.23 suppresses startup messages in catalina.out and Tomcat v7.0.52 displays them all in catalina.out. Also Tomcat 7.0.23 starts up much faster than Tomcat v7.0.52. Contexts are served immediately upon a v7.0.23 restart. I used the same logging.properties file from 7.0.23 into 7.0.52. I would like to avoid the context being redeployed every time v7.0.52 starts up. Here are some details: (1) Startup Times: v7.0.23 starts up in a couple of minutes at most (can't see exact times as they are not captured in catalina.out) v7.0.52 starts up in 479924 ms -- so so long! (2) Catalina.out messages: v7.0.23 catalina.out is empty. --v7.0.52 catalina.out snippet:--- Apr 3, 2014 9:07:24 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_1.xml Apr 3, 2014 9:07:28 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_2.xml ... Apr 3, 2014 9:07:31 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_136.xml ... Apr 3, 2014 9:15:04 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 479924 ms --end of v7.0.52 catalina.out snippet:--- (3) Contexts after a restart: After a restart, the contexts load up right away with v7.0.23 rather than a Service Temporarily Unavailable as in 7.0.52. (4) My Questions are: -- a.) How can I prevent contexts from being redeployed? I have 136 contexts under /opt/tomcat/apache/conf/Catalina/localhost/ and these are deployed everytime I restart v7.0.52 I don't think JARs are scanned in 7.0.52 for things to slow down so much. Not sure if metadata-complete=true will help here. Running all the FIleHandlers in FINEST mode shows nothing while contexts are being deployed. But I can see time being spent as each context is deployed. b) I want to speed up the startup times in v7.0.52 drastically. Thanks for all help! -Shanti
RE: Specific class loading in my webapp
Ok I will try next week, If I can load several jars in a specific directory with VirtualWebappClassLoader, it good :-) Thank Christopher Daniel Bien cordialement, Adrien Ruffié LD : +33 1 73 03 29 50 Tél : +33 1 73 03 29 80 E-DEAL Innover la Relation Client -Message d'origine- De : Christopher Schultz [mailto:ch...@christopherschultz.net] Envoyé : jeudi 3 avril 2014 18:11 À : Tomcat Users List Objet : Re: Specific class loading in my webapp -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adrien, On 4/3/14, 3:53 AM, Adrien RUFFIE wrote: I search a means to force my webapp when is deploy in tomcat, to take several jars/classes in located in a specific directory. For example when my webapp start, it load jars into /var/lib/my-repository/ Is it possible to do this directly with a classloader in my webapp, and also dynamically reload classes. Or it's only tomcat configuration ? Thank you very much and best regards You can specify your own Loader[1] under Context. Feel free to write your own ClassLoader, but it has better implement the requirements of a web application ClassLoader. The VirtualWebappClassLoader (as suggested by Daniel) is a special case: it's a ClassLoader that's already been written for you. Before you write your own ClassLoader, try VWCL and ask here if you can't get it to meet your requirements. It's easy to write your own broken ClassLoader. - -chris [1] http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPYgyAAoJEBzwKT+lPKRYUDQQAMOOWZRnxhHgy4C+PxiKs2UI YKHornJLXPeQ4/zPg4ZfO+siFzjpdiDhI7kbO+ms2/oY1NioxpjAOSglTOLYIZCg bX7SX21ubk6jDe1dKcBtc96H6PgxtypQOYIM/rkzVJYWcAAdIrPPutZdSMijdRJq H9xoULEqtffVPTgfX3KP5b8Y56vE89ys06E1/ygckh876DV2kuZUaKXKiSUzI41W tWcroAOS/zaEledBzkGq/bPtqzrYfSvFwEATgX0L+Tm/1lYhXfn/377qr41rGuDV SfPIT6dQWqw4dXBJf25uXJhGxLeLdZs8J50RDgtnLs0mQpzLrx3xkGhyUEXMZAZa mwSDMc+yRKmCc6FNqjhFY8Y1RV31VYgtCo04+9ZFSiZsUp3Y7rQa40co4WnZkZ0c wmDCSzTx26aE1RlT4IEOE/Z5xhfSFTcFJrg3I5xYgOUawZGYbJPVSdOrulp89d66 qahKelULTNV1qoLcj0S2G2t5NZx+JBkw35QJ8LsDo9uRvo+uwlIBqDA+OUbWalfB e2cdNI5S83GR0ZpNnUqa9pdy9vSqm7tsQTgMx5nw9Dup9v6wwwdWnIMULn99OrDf Xs8h/IvXDA42WP49jooVhl8a7dLfv9kubxu8AQ/Q5R0cMZgRR/b0ilzShMxlhPDp No2spC3lLYrWFBL4Rruv =3KZa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: catalina.out anomaly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shanti, On 4/3/14, 12:19 PM, Shanti Suresh wrote: I am unable to understand how Tomcat v7.0.23 suppresses startup messages in catalina.out and Tomcat v7.0.52 displays them all in catalina.out. They work the same way. Are you launching them differently for different versions? Also Tomcat 7.0.23 starts up much faster than Tomcat v7.0.52. Contexts are served immediately upon a v7.0.23 restart. At some point, Tomcat was modified to adhere to some rulings made by the Servlet EG about JAR-scanning and other (unfortunately) time-consuming operations. You can speed-up Tomcat startup by using metadata-complete=true in your web.xml, and configuring the various JAR-scanning options. https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#JAR_Scanning I used the same logging.properties file from 7.0.23 into 7.0.52. I would like to avoid the context being redeployed every time v7.0.52 starts up. If your context is not deployed, then your web application will not respond to requests. Are you sure you don't want it deployed? Here are some details: (1) Startup Times: v7.0.23 starts up in a couple of minutes at most (can't see exact times as they are not captured in catalina.out) They should be. v7.0.52 starts up in 479924 ms -- so so long! That is a very long time. Can you take some thread dumps during the process. You certainly have a long time for that opportunity. (2) Catalina.out messages: v7.0.23 catalina.out is empty. How do you launch Tomcat 7.0.23? --v7.0.52 catalina.out snippet:--- Apr 3, 2014 9:07:24 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_1.xml Apr 3, 2014 9:07:28 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_2.xml ... Apr 3, 2014 9:07:31 AM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/tomcat/delivery/apache-tomcat-7.0.52/conf/Catalina/localhost/context_136.xml ... So Tomcat is deploying context_136 which is presumably your web application. Why does your web application take so long to launch? Apr 3, 2014 9:15:04 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 479924 ms --end of v7.0.52 catalina.out snippet:--- (3) Contexts after a restart: After a restart, the contexts load up right away with v7.0.23 rather than a Service Temporarily Unavailable as in 7.0.52. (4) My Questions are: -- a.) How can I prevent contexts from being redeployed? I have 136 contexts under /opt/tomcat/apache/conf/Catalina/localhost/ and these are deployed every time I restart v7.0.52 So you want Tomcat to come up immediately without any applications available? That's no fun. I don't think JARs are scanned in 7.0.52 for things to slow down so much. Are you sure? Take thread dumps. Not sure if metadata-complete=true will help here. Running all the FIleHandlers in FINEST mode shows nothing while contexts are being deployed. Then you have done something wrong. When I set level=FINEST, I get so much logging it noticeably slows down the startup of my Tomcat instance. But I can see time being spent as each context is deployed. b) I want to speed up the startup times in v7.0.52 drastically. How long does Tomcat take to launch if you have no web applications? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPY7tAAoJEBzwKT+lPKRY/X4P/09VdkSTyuyQuKB5fDky+eFq DzpTGRWcLWhFb+nUbIhq6k7VCxXn7UhmtLE7Gsg0XiJf6xguouaxVtuJuD/8XzXm VFplalAWa0IH0FfhXDqPOtN08sGIY7KxsjHemt+Kfa6ApCrtDbcnK8okp9J2BJln hXlCUwuQ+shfv4bngkdT1c7woBP/cWJsy9Y56nb2VL3mNZpDqsKg6ec2YeXOxGGT iJiuqJiqJk6C2cA/k1qpIa56uq1xH3vzK943My9gilSVwJ9CfAqo9GRdt6uCWT9P ryiTRh0Oss3IgnwPA3S5ysVRtEVG+g4lFT3SlCgn3O/MTI8V+mMLgJpU09qqWG2F Efbe1VDDVaa8uJa5GoqfTGvlyJPa39t6xnJnQaSL2fOQ8qHj9BqTEzZY/BbEpgO8 gKdGn4SgVNmIf1nKAEiDx1dnpyoLZSWrT3Xy56iPMVrDQ522tsOY79xs9tjIPOjv gaMN9yCbY8mn6kv0bAzYgHTGOrLlkcNks+4VTbRiw6I/L2TxhvXs2YkMnt8KZfFt 0b2emzcXPXwRV5wXsy+5dpHi1qYuylaWrZv2skkQQqpXUEebQVMx2yznAQiJEB3a W9GyEyScrdzHBZQuR1uUlV7DCXq3VKDmxtBA1Ti/bwfns1l5oSa3E2nnnF7RVW47 IXOtJRE9sz2iegTy3ld/ =5gve -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Catalina start problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neeraj, On 4/2/14, 4:23 AM, Neeraj Sinha wrote: I am trying to start tomcat on linux and I am getting LifecycleException exception whose snippet is below: Apr 2, 2014 8:33:53 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_38/jre/lib/amd64/server:/usr/java/jdk1.6.0_38/jre/lib/amd64:/usr/java/jdk1.6.0_38/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-bio-8080] Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [ajp-bio-8009] Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 890 ms Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start SEVERE: Catalina.start: org.apache.catalina.LifecycleException: Failed to start component [StandardServer[8005]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.startup.Catalina.start(Catalina.java:684) 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:322) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451) Caused by: java.lang.NoSuchMethodError: org.apache.naming.NamingContext.setExceptionOnFailedWrite(Z)V at org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:264) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:724) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 7 more Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 6 ms One reason I could guess for this is that Tomcat jar may not be proper but I have checked that and that looks fine to me. Appreciated if somebody could help me. What version of Tomcat are you trying to run? Have you modified your Tomcat installation other than changes to server.xml and adding web applications to it? Do any of your web applications have any Tomcat JAR files in them? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPZwDAAoJEBzwKT+lPKRYICEQALVfnTT7vGzt1ICafuznVYn1 Wz778Ij8WtbY8FDDfvtJREyf+4Xcw1YAsQa4acSkjmFRZW9AHE+BMFs82dYiVO3q 9XktiZOGJ1cfc2WqGD4NlRIC4u0lnPJau0js/vf2je3fd61sixh5+r7Lwftp7fQ1 9QsAEIZG3XHmrEVVrw1iMwm5fEAPSokBJX6Dxe2SA3hmKddgME2lYuenZLuiVjmm OQyntOdMlrSLQGQdBNbdR3cLSoDbLXTXkGCWy5/Xsjn9inKXC2fZdbzqShwT3+C6 o9nbpzLjM2l1EHnig+qYw9oEUhEAfdohtk3h2csJsIpX/Qndh2PnoeuGdmBRC+B0 UDGFDOMhx3HLjbK9Lvt86q7LL5ZCeNQPCe/3OpcgsV8OST1wO3mFcwoBPQhFSkks pIlSu9t9NkbWBQf9TiFxVPl2YG3byvdgTT/puN094HN+Swbt7OZ7aRUIuisDEl6Q I7qetrOTh4O29mLBs2YHYx9UmMbbtXNR+ODppzD7CmHqIFWVparDPTFHgdqAT8ES Bj9QMUKZ5uCCL0/KpR0M6swBNeeu1k0OCvLjrE536KUSTv9LQnltDRv+xSrHnnp3 FUSnWYFRGP8w1t07LQ2e6JGd5/YoEUEVcldfh9wx4hks/+XEx2/bR/gRHmHPLz7j mejeP0348u/4sRBOfeqq =UiH3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Valid certificate chain failing with unable to find valid certification path to requested
I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server; 8 processor
cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance(TLS);
sc.init(null, null, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true);
try (OutputStreamWriter output = new
OutputStreamWriter(urlConnection.getOutputStream(), UTF-8)) {
output.write(msg.writeNodes(false));
output.write(\n);
output.flush();
}
On getting the urlConnection.getOutputStream() the following exception is
thrown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException:
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet’s “Hello World” message from a web browser. Chrome says
that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.x.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS)
The certificate should be trusted by all major web browsers (all the
correct intermediate certificates are installed).
The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xx.net) is correctly listed in the certificate.
Common name: www.x.net
SANs: www.xx.net, xx.net
Valid from April 3, 2014 to April 3, 2015
Serial Number: 0431cbc326fefc
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Secure Certificate Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc.
Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Root Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2
Organization: GoDaddy.com, Inc.
Location: Scottsdale, Arizona, US
Valid from August 31, 2009 to December 31, 2037
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Root Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the server.xml are
the same except for the hostnames and the keystore password. The server with
the problem is not using the default keystorepassword of changeit
Any help would be greatly appreciated.
Jeff Crump
Re: Valid certificate chain failing with unable to find valid certification path to requested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.cr...@gmail.com wrote:
I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
8 processor cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance(TLS); sc.init(null, null,
null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true); try (OutputStreamWriter output =
new OutputStreamWriter(urlConnection.getOutputStream(), UTF-8))
{ output.write(msg.writeNodes(false)); output.write(\n);
output.flush(); }
Looks fairly innocuous.
On getting the urlConnection.getOutputStream() the following
exception is thrown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet’s “Hello World” message from a web browser.
Chrome says that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.x.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS) The certificate should be
trusted by all major web browsers (all the correct intermediate
certificates are installed). The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xx.net) is correctly listed in the
certificate. Common name: www.x.net SANs:
www.xx.net, xx.net Valid from April 3, 2014 to
April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2 Organization:
GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the
server.xml are the same except for the hostnames and the keystore
password. The server with the problem is not using the default
keystorepassword of changeit
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
Chris,
Sent from Windows Mail
From: Christopher Schultz
Sent: Thursday, April 3, 2014 1:55 PM
To: Tomcat Users List
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.cr...@gmail.com wrote:
I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
8 processor cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance(TLS); sc.init(null, null,
null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true); try (OutputStreamWriter output =
new OutputStreamWriter(urlConnection.getOutputStream(), UTF-8))
{ output.write(msg.writeNodes(false)); output.write(\n);
output.flush(); }
Looks fairly innocuous.
On getting the urlConnection.getOutputStream() the following
exception is thrown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet’s “Hello World” message from a web browser.
Chrome says that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.x.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS) The certificate should be
trusted by all major web browsers (all the correct intermediate
certificates are installed). The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xx.net) is correctly listed in the
certificate. Common name: www.x.net SANs:
www.xx.net, xx.net Valid from April 3, 2014 to
April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2 Organization:
GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the
server.xml are the same except for the hostnames and the keystore
password. The server with the problem is not using the default
keystorepassword of changeit
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Alten, Jessica-Aileen wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014 15:36 An: Tomcat Users List Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between- ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do ping localhost. It should tell you what it understands by localhost. Copy and paste the result here : ping localhost Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms That /is/ bizarre. As far as I know, to resolve hostnames in its configuration, mod_jk/isapi is using the OS's resolver library, the same as the one ping should be using. On the other hand, you say that if you have worker.ajp13w.host=localhost it doesn't work (mod_jk cannot connect to tomcat), but when you change this to worker.ajp13w.host=127.0.0.1 then it works fine. Ok, another check in a command window (and I assume that you open this command window *on the server itself* where mod_jk and Tomcat are running, right ?) test : 1) telnet localhost 8009 2) telnet 127.0.0.1 8009 Any difference between these 2 cases ? If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39 problem. In any case, you cannot connect to 0.0.0.0, as this log line would suggest : jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed Rainer ? Mladen ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/3/14, 3:34 PM, André Warnier wrote: Alten, Jessica-Aileen wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014 15:36 An: Tomcat Users List Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between- ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do ping localhost. It should tell you what it understands by localhost. Copy and paste the result here : ping localhost Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms That /is/ bizarre. As far as I know, to resolve hostnames in its configuration, mod_jk/isapi is using the OS's resolver library, the same as the one ping should be using. On the other hand, you say that if you have worker.ajp13w.host=localhost it doesn't work (mod_jk cannot connect to tomcat), but when you change this to worker.ajp13w.host=127.0.0.1 then it works fine. Ok, another check in a command window (and I assume that you open this command window *on the server itself* where mod_jk and Tomcat are running, right ?) test : 1) telnet localhost 8009 2) telnet 127.0.0.1 8009 Any difference between these 2 cases ? If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39 problem. In any case, you cannot connect to 0.0.0.0, as this log line would suggest : jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed Could this be an interaction between IPv4 and IPv6? Try: C: nslookup localhost You might get only 127.0.0.1 or you might also get :: (or something equivalent). I'm not sure why it wasn't happening with earlier versions of mod_jk (which?). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPdQeAAoJEBzwKT+lPKRY6i4P/jv+ozeg+saTWEDwWeR769JQ 1d3Y3n9Cnvk5qHlvEkTxOzu72MdUtl3+eLLgCT+7QNRQWr3m/Lj+vlN8E+M0d/6X BWs8/XDP3fMyc6eBgQiTQWTZUMH1sGua4ceJ24PLviK1Pq9jambFeHHvdYluDK4K ItgDyfXf9GkO5SsMvQxcic2VpjPxkPwM6W3ndjvDGYAucwK3ZW5FQTZ0GAsmvYac 6jGa7UJWCJA0VemInPIR0J5wlOpDq+GtjKTBaGltAbgVew7U91uuCyB9ll9Ybrug buETKMaB/o+P57e3atUoWRz5/pUAaZJDE75HDguKS+z2Io5SXR7zOynOhqso89em kTZ5UvpuO8ffeqqTn9WK7y8roGcYP+PBDdmBgbZF3RysFw+sLaWaRP08rPHMPe7X Yiw0pZbxSAEwlBcPiPrueqjHxiC1jtGFfpFqaywrNfAkDKSWl/ckzenAZzRlwimS G0cpbLxGPnvQaqf58jvkntd102tGSMgb7mhVTNDsCu0+IFRfuN+iFy76LpgMwcYc dZUL5r23gj5Vqe5f9k9GdI8sF6XLPf7juoUXJKRIer9wLhNvTeriv0jCnWhk7SqQ ysHmtssDzV6jAF9fsGGWrtYTD/LE9NY+WTSDAMv+hZTn/OQZRUPGZ4XS3UN1HE1P 1OWrGlm0IGcgZFzqPRTA =JW/W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
On Thu, Apr 3, 2014 at 2:58 PM, jeffery.scott.cr...@gmail.com wrote:
Chris,
Sent from Windows Mail
From: Christopher Schultz
Sent: Thursday, April 3, 2014 1:55 PM
To: Tomcat Users List
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.cr...@gmail.com wrote:
I'm using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
8 processor cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance(TLS); sc.init(null, null,
null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true); try (OutputStreamWriter output =
new OutputStreamWriter(urlConnection.getOutputStream(), UTF-8))
{ output.write(msg.writeNodes(false)); output.write(\n);
output.flush(); }
Looks fairly innocuous.
On getting the urlConnection.getOutputStream() the following
exception is thrown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet's Hello World message from a web browser.
Chrome says that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.x.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS) The certificate should be
trusted by all major web browsers (all the correct intermediate
certificates are installed). The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xx.net) is correctly listed in the
certificate. Common name: www.x.net SANs:
www.xx.net, xx.net Valid from April 3, 2014 to
April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2 Organization:
GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the
server.xml are the same except for the hostnames and the keystore
password. The server with the problem is not using the default
keystorepassword of changeit
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-END PGP SIGNATURE-
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/3/14, 3:34 PM, André Warnier wrote: Alten, Jessica-Aileen wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014 15:36 An: Tomcat Users List Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is localhost == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be 127.0.0.1 ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between- ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse worker.ajp13w.host=localhost, instead localhost must be replaced with 127.0.0.1, this works! In my eyes this is a big fat bug, because most documentation on workers use localhost. localhost is actually the default for the host connection directive. The new worker directive prefer_ipv6 doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do ping localhost. It should tell you what it understands by localhost. Copy and paste the result here : ping localhost Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms That /is/ bizarre. As far as I know, to resolve hostnames in its configuration, mod_jk/isapi is using the OS's resolver library, the same as the one ping should be using. On the other hand, you say that if you have worker.ajp13w.host=localhost it doesn't work (mod_jk cannot connect to tomcat), but when you change this to worker.ajp13w.host=127.0.0.1 then it works fine. Ok, another check in a command window (and I assume that you open this command window *on the server itself* where mod_jk and Tomcat are running, right ?) test : 1) telnet localhost 8009 2) telnet 127.0.0.1 8009 Any difference between these 2 cases ? If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39 problem. In any case, you cannot connect to 0.0.0.0, as this log line would suggest : jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed Could this be an interaction between IPv4 and IPv6? Try: C: nslookup localhost You might get only 127.0.0.1 or you might also get :: (or something equivalent). I'm not sure why it wasn't happening with earlier versions of mod_jk (which?). (versions : her first post mentioned the versions she was comparing) I previously asked Jessica-Aileen to do a ping localhost on the machine, see results above. It definitiely pings 127.0.0.1 .. (assuming it was done on the same machine) And I don't think that nslookup uses the local resolver. When I'm doing that on my Windows laptop, for localhost it responds not found (in many more German words) C:\Dokumente und Einstellungen\awnslookup localhost Server: fire-see.localdomain Address: 192.168.245.253 *** localhost wurde von fire-see.localdomain nicht gefunden: Non-existent domain On the other hand, it does this (spot the difference..): C:\Dokumente und Einstellungen\awnslookup localhost. Server: fire-see.localdomain Address: 192.168.245.253 Name:localhost Address: 127.0.0.1 (But that of course could be the localhost of my DNS server, since it happens to be a Linux box running dnsmasq, and it has that name in it's own hosts file.) Mmmm. If only by curiosity, maybe Jessica-Aileen could try worker.ajp13w.host=localhost. (ending in dot) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
On 4.4.2014 0:27, Toby Lazar wrote: As others have noted here on other threads, you can use: http://portecle.sourceforge.net/ to see exactly which certificates your server is providing clients (Examine SSL/TLS connection). Viewing server certificates via browsers can be misleading since they don't distinguish within the chain between certificates provided by the server and those already trusted by the client (browser). You also may double check your chain using other online tools like: https://www.ssllabs.com/ssltest/ http://www.digicert.com/help/ I never used SSLShopper, so I don't know how reliable it is. Another way to check certificate chain directly in server keystore is keytool -list -keystore server.jks -v To check Chris' assumption about missing ROOT certificate on the client, you may turn on TLS debugging on the client using JVM option -Djavax.net.debug=all At start it will print all root certificates trusted by the client. It may reveal that your system ROOT CA list on the client is outdated, messed up, or overriden with e.g. JVM option -Djavax.net.ssl.trustStore. It will also print TLS handshake details. Jefferey: The hostname (www.xx.net) is correctly listed in the certificate. Common name: www.x.net SANs: www.xx.net, xx.net Check if your Java code indeed uses one of those URL's listed in the certificate (www.xx.net, xx.net), and not some third one not listed in the certificate, or IP address. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
I've only barely glanced at this thread, so forgive me if I'm saying something that's already been mentioned, or that's irrelevant. But yesterday, I was tearing my hair out over something similar while setting up a keystore for a customer: it seems that the customer's CA of choice had assumed that the customer was using the same keystore that they'd used previously (I'd created a new one because of some changes in ownership and location information), and so they'd signed the CSR with the OLD intermediate certificates, without bothering to tell anybody. And so every time I tried to plug the response certificate in with the NEW intermediates, Keytool would balk. I dunno what possessed me to try the old intermediates, but try them I did (by that time, I'd also found and installed KeyStore Explorer, a nifty little open-source Keytool-replacement). (Ironically, because installing a CSR response certificate is a bit counter-intuitive in KeyStore Explorer [it's ONLY on the right-click menu, and ONLY if you right-click on a keypair], the keystore I made using it was worthless, but once I'd discovered the problem, I'd also done one with Keytool as a backup. Didn't find out I'd screwed up the KeyStore Explorer version until this afternoon, and didn't figure out the right way to do it in KeyStore Explorer until after I'd already put the Keytool version of the keystore into service.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
I tried ssllabs but it doesn't support SSL on port 8443, but digicert did show that everything was correct in the chain. I've run my client program with the -Djavax.net.debug=all option. First it listed out all of the trusted authorities. Mine is GoDaddy and this is the record: 04/03/2014 07:42:56 PM adding as trusted cert: 04/03/2014 07:42:56 PM Subject: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Issuer: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Algorithm: RSA; Serial number: 0x0 04/03/2014 07:42:56 PM Valid from Tue Jun 29 12:06:20 CDT 2004 until Thu Jun 29 12:06:20 CDT 2034 This is what I think is the relevant part: [3]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen:2147483647 ] How can I tell what that is or how to remove it? Thanks, Jeff Sent from Windows Mail From: James H. H. Lampert Sent: Thursday, April 3, 2014 8:12 PM To: Tomcat Users List I've only barely glanced at this thread, so forgive me if I'm saying something that's already been mentioned, or that's irrelevant. But yesterday, I was tearing my hair out over something similar while setting up a keystore for a customer: it seems that the customer's CA of choice had assumed that the customer was using the same keystore that they'd used previously (I'd created a new one because of some changes in ownership and location information), and so they'd signed the CSR with the OLD intermediate certificates, without bothering to tell anybody. And so every time I tried to plug the response certificate in with the NEW intermediates, Keytool would balk. I dunno what possessed me to try the old intermediates, but try them I did (by that time, I'd also found and installed KeyStore Explorer, a nifty little open-source Keytool-replacement). (Ironically, because installing a CSR response certificate is a bit counter-intuitive in KeyStore Explorer [it's ONLY on the right-click menu, and ONLY if you right-click on a keypair], the keystore I made using it was worthless, but once I'd discovered the problem, I'd also done one with Keytool as a backup. Didn't find out I'd screwed up the KeyStore Explorer version until this afternoon, and didn't figure out the right way to do it in KeyStore Explorer until after I'd already put the Keytool version of the keystore into service.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
On Thu, Apr 3, 2014 at 10:03 PM, jeffery.scott.cr...@gmail.com wrote: I tried ssllabs but it doesn't support SSL on port 8443, but digicert did show that everything was correct in the chain. Your certificate is a good certificate but it doesn't mean your client should trust it. ssllabs may trust a different set of issuers than your client. I've run my client program with the -Djavax.net.debug=all option. First it listed out all of the trusted authorities. Mine is GoDaddy and this is the record: That one is not the issuer of your certificate. GoDaddy has many issuing certificates. The GoDaddy certificate the client trusts expires in 2034 whereas your issuer certificates expire in 2031/2037. Also, the DNs are different. Better to identify the trusted certificate by serial number and subject key identifier. 04/03/2014 07:42:56 PM adding as trusted cert: 04/03/2014 07:42:56 PM Subject: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Issuer: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Algorithm: RSA; Serial number: 0x0 04/03/2014 07:42:56 PM Valid from Tue Jun 29 12:06:20 CDT 2004 until Thu Jun 29 12:06:20 CDT 2034 This is what I think is the relevant part: [3]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen:2147483647 ] I don't think this is your problem. Your problem is that you lack a chain of trust from your server certificate to one that the client already trusts. If your server is only serving up its own server certificate and not the intermediate one, try adding that to your config. You can test this out with portecle or another tool. Toby How can I tell what that is or how to remove it? Thanks, Jeff Sent from Windows Mail From: James H. H. Lampert Sent: Thursday, April 3, 2014 8:12 PM To: Tomcat Users List I've only barely glanced at this thread, so forgive me if I'm saying something that's already been mentioned, or that's irrelevant. But yesterday, I was tearing my hair out over something similar while setting up a keystore for a customer: it seems that the customer's CA of choice had assumed that the customer was using the same keystore that they'd used previously (I'd created a new one because of some changes in ownership and location information), and so they'd signed the CSR with the OLD intermediate certificates, without bothering to tell anybody. And so every time I tried to plug the response certificate in with the NEW intermediates, Keytool would balk. I dunno what possessed me to try the old intermediates, but try them I did (by that time, I'd also found and installed KeyStore Explorer, a nifty little open-source Keytool-replacement). (Ironically, because installing a CSR response certificate is a bit counter-intuitive in KeyStore Explorer [it's ONLY on the right-click menu, and ONLY if you right-click on a keypair], the keystore I made using it was worthless, but once I'd discovered the problem, I'd also done one with Keytool as a backup. Didn't find out I'd screwed up the KeyStore Explorer version until this afternoon, and didn't figure out the right way to do it in KeyStore Explorer until after I'd already put the Keytool version of the keystore into service.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SQLNestedException in Connection Pooling With Tomcat 7.0.39
Dear All,
I am doing connection pooling with tomcat 7.0.39 and MySQL 5.5.After
searching on google and with your help i have done the below things.
Even i am able to get the connection successfully using this but getting
some trouble and exception.
I am explaining you all steps done by me-
*1. Have created a context.xml*
I have put this context.xml in the META-INF folder of my application. but
when i am deploying the web app to the server then it is not creating its
copy to ${CATALINA-BASE}/conf/Catalina/locathost. Why is that so ?
But when i am putting this context.xml in ${CATALINA-BASE}/conf folder then
its working.
?xml version=1.0 encoding=UTF-8?
Context
Resource name=jdbc/MaxDB auth=Container type=javax.sql.DataSource
maxActive=100 maxIdle=30 maxWait=-1
username=root password=root
driverClassName=com.mysql.jdbc.Driver
url=jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull/
/Context
*2. Mapping in web.xml*
resource-ref
descriptionMySql DataSource/description
res-ref-namejdbc/MaxDB/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref
*3. Then on my servlet i am getting the object of connection like this-*
private static InitialContext ic;
protected static DataSource datasource;
private static Context ctx;
public void doSomeStuff() throws DatabaseException
{
Connection conn = null;
try
{
conn= getConnection();
.
// do the required stuff
}
catch (Exception ex)
{
}
finally
{
conn.close();
}
}
*4. This is the method in my DAO Class i am using this method to get the
object of connection at all of my servlet.*
protected static Connection getConnection() throws DatabaseException
{
Connection conn = null;
try
{
ctx = new InitialContext();
datasource = (DataSource)
ctx.lookup(java:/comp/env/jdbc/MaxDB);
conn = datasource.getConnection();
}
catch (Exception ex)
{
}
return conn;
}
Using all this i am able to get connection. But if number of hits increases
to the server and Initially i got the the below exception-
*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
pool error Timeout waiting for idle object*
Then i got the exception-
*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create
PoolableConnectionFactory (Access denied for user 'root'@'localhost' (using
password: YES))*
Please assist me to know the root cause of the problem. I have searched it
on google and have read lots of forum but did not get the satisfactory
answer.
Hope that you all are expert and your suggestion will be valuable for me.
Thanking You!
*Best Regards,*
*Saurabh Sarasvat*
