Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
Deme Carv wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. Well, if it is working in Tomcat but not in Websphere, then are you not asking your question on the wrong help forum ? I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - 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: NoSuchMethodError: org/apache/xml/utils/TreeWalker
André Warnier wrote: Deme Carv wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. Well, if it is working in Tomcat but not in Websphere, then are you not asking your question on the wrong help forum ? I have searched for hours in web but I didn't find nothing that I could at least give a try. Addendum : You could try asking here : http://www.websphereusergroup.org/go/forum/view/108057/185109/websphere_application_server (found after a single Google search for websphere help forum) I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV NoSuchMethodErrors often occur when you have the wrong version of a library on your class path. This happens because your code is looking for one version, that has method X while the library you've included has a different version without method X. I don't know a lot about WebSphere, but I do recall that it ships with an older set of libraries and that it prefers those libraries (it calls this parent first) over ones in the application (it calls this parent last). I've seen cases where switching to parent last mode has resolved similar issues. If that doesn't help, I second André's suggestion to look for help in a more appropriate forum. Dan at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Application Already Running Message at Login
I recently uninstalled Tomcat 6 and installed Tomcat 7.0.42 on a Windows Server 2008 R2. Tomcat is installed as a service on this machine, set to automatically start at system boot. There is also an icon in the tray of the service account that owns the software to start and stop Tomcat. Whenever I login to the server as the service account, I receive the message An instance of the 'Tomcat7' application is already running. Where can I check and turn off where it is trying to start Tomcat on login, as it is already running as a service? Christine Fletcher
COMET End event subtype= null
I am developing a COMET application that is primarily based on the example given on the documentation of the chat server. My problem is that when two users connect, the connection held open by the comet servlet is closed. I know this because I am getting END events in my log. The confusing part is, it will randomly fail, and when it does, subtype is null. When I say randomly fail, I mean get the END event when you are not supposed to. Does subtype being null point to anything? This is so frustrating because it fails randomly. I am on Tomcat7 on linux. I can provide more info if its needed
SSL redirect problems
TC 7.0.54 / RHEL 6 I have two physical servers, each running an instance of TC. The servers are behind a hardware loadbalancer. IPTables is routing request on 80 to 8080. Tomcat runs under a non-root user. All good. I needed to protect an area of our webapp under SSL. Went ahead and installed the cert on each server. I can go directly to each server by IP under SSL and get the cert (with the expected IP doesn't match FQDN warning). But when I go through the loadbalancer I can't access anything under port 8443. I redirected 443 to 8443 on each TC server using IPTables, but still no luck. Is there anything I'm missing? I understand I can install the cert on the loadbalancer instead, or use httpd as a proxy, but I'd rather just leave it the way it is if there's any other option. TIA, John
Re: COMET End event subtype= null
ok looks like i have the configuration of org.apache.catalina.valves.CometConnectionManagerValve wrong. sorry about that. Still have the random disconnect error though On Fri, Aug 1, 2014 at 10:46 AM, Elias Kopsiaftis yemi...@gmail.com wrote: I am developing a COMET application that is primarily based on the example given on the documentation of the chat server. My problem is that when two users connect, the connection held open by the comet servlet is closed. I know this because I am getting END events in my log. The confusing part is, it will randomly fail, and when it does, subtype is null. When I say randomly fail, I mean get the END event when you are not supposed to. Does subtype being null point to anything? This is so frustrating because it fails randomly. I am on Tomcat7 on linux. I can provide more info if its needed
Re: SSL redirect problems
On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote: TC 7.0.54 / RHEL 6 I have two physical servers, each running an instance of TC. The servers are behind a hardware loadbalancer. IPTables is routing request on 80 to 8080. This seems unnecessary. If you have a hardware load balancer in front of Tomcat, it is the only thing that would ever talk to Tomcat. Thus if you just configure it to go to port 8080 you don't need the iptables rule. I can't imagine it's hurting anything, but just thought I'd mention it. Tomcat runs under a non-root user. All good. I needed to protect an area of our webapp under SSL. Went ahead and installed the cert on each server. I can go directly to each server by IP under SSL and get the cert (with the expected IP doesn't match FQDN warning). You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. Ex: browser - HTTPS - load balancer - HTTP or HTTPS - Tomcat If you put an SSL certificate on your Tomcat servers, that would allow you to secure the connection between your load balancer and Tomcat. Depending on your network and security requirements this may or may not be necessary. I'd say most people don't do this because terminating SSL on the load balancer is sufficient. It just depends on your requirements though. But when I go through the loadbalancer I can't access anything under port 8443. I redirected 443 to 8443 on each TC server using IPTables, but still no luck. Is there anything I'm missing? The load balancer is almost certainly listening on port 80 and 443. To test, you'd want to connect to the load balancer on one of those ports. The load balancer would then connect to one of your backend nodes and proxy the request on your behalf. Your browser will not connect directly to the backend nodes (see my point above about not needing the iptables rule), unless you specifically point it to the ip address of one of the backend nodes. I understand I can install the cert on the loadbalancer instead, or use httpd as a proxy, but I'd rather just leave it the way it is if there's any other option. I think you'd want it on the load balancer. Possibly with additional certs on your backend nodes, if you want HTTPS communication between the load balancer and the Tomcat nodes. Dan
Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
Fistlly, thank you both of all for answering. I am very glad for very rapid comments. I attached a file in my original question which tells the jar I have in both situation. I guess it might not be delivered to the forum. I know that there is RAD involved but there are as well apache libraries included and I am sure there are a lot of people in this forum with huge experience in such libraries. I don't think my root cause is related to the Websphere server. I guess that there are some conflict between jars. Even though you might think different, could you at least tell me if you see some conflict in this libraries? The problem arises when apache.xalan.serialize.SerializerToXML run with libraries below. C:\IBM\SDP\runtimes\base_v61\lib C:\Rad\workspace\my_app\WebContent\WEB-INF\lib.eclipseproductactivation.jar activation-impl.jarclasses12.jaraspectjrt.jarcommons-collections.jarbase.jar commons-fileupload.jarbootstrap.jarcommons-io-1.4.jarbsf-engines.jar commons-logging.jarcommandlineutils.jaribmjzos.jarEJBCommandTarget.jar javax.jarffdcSupport.jarjstl.jarhtmlshell.jarjta.jarinstallver.jarjzos.jar installxml.jarlog4j-1.2.14.jariscdeploy.jarmail.jarivblogbr.jar quartz-1.6.0.jarIVTClient.jarquartz-all-1.6.0.jarj2ee.jarspring.jarjacl.jar standard.jarlaunchclient.jarxalan-2.4.1.jarlmproxy.jarxerces-1.4.4.jar mail-impl.jarmarshall.jarnif.jarpc-appext.jarphysicalrep.jarpmirm4arm.jar rrd-appext.jarrsadbutils.jarrsahelpers.jarserviceadapter.jar sib.api.jmsra.rarsib.ra.rarsljc.jarspy-sl.jarspy.jarsqlserver.jarstartup.jar tcljava.jarurlprotocols.jarutil.jarwsatlib.jarwsif-compatb.jar 2014-08-01 9:05 GMT-03:00 Daniel Mikusa dmik...@pivotal.io: On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV NoSuchMethodErrors often occur when you have the wrong version of a library on your class path. This happens because your code is looking for one version, that has method X while the library you've included has a different version without method X. I don't know a lot about WebSphere, but I do recall that it ships with an older set of libraries and that it prefers those libraries (it calls this parent first) over ones in the application (it calls this parent last). I've seen cases where switching to parent last mode has resolved similar issues. If that doesn't help, I second André's suggestion to look for help in a more appropriate forum. Dan at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL redirect problems
Daniel Mikusa wrote: On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote: TC 7.0.54 / RHEL 6 I have two physical servers, each running an instance of TC. The servers are behind a hardware loadbalancer. IPTables is routing request on 80 to 8080. This seems unnecessary. If you have a hardware load balancer in front of Tomcat, it is the only thing that would ever talk to Tomcat. Thus if you just configure it to go to port 8080 you don't need the iptables rule. I can't imagine it's hurting anything, but just thought I'd mention it. Tomcat runs under a non-root user. All good. I needed to protect an area of our webapp under SSL. Went ahead and installed the cert on each server. I can go directly to each server by IP under SSL and get the cert (with the expected IP doesn't match FQDN warning). You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. Ex: browser - HTTPS - load balancer - HTTP or HTTPS - Tomcat If you put an SSL certificate on your Tomcat servers, that would allow you to secure the connection between your load balancer and Tomcat. Depending on your network and security requirements this may or may not be necessary. I'd say most people don't do this because terminating SSL on the load balancer is sufficient. It just depends on your requirements though. But when I go through the loadbalancer I can't access anything under port 8443. I redirected 443 to 8443 on each TC server using IPTables, but still no luck. Is there anything I'm missing? The load balancer is almost certainly listening on port 80 and 443. To test, you'd want to connect to the load balancer on one of those ports. The load balancer would then connect to one of your backend nodes and proxy the request on your behalf. Your browser will not connect directly to the backend nodes (see my point above about not needing the iptables rule), unless you specifically point it to the ip address of one of the backend nodes. I understand I can install the cert on the loadbalancer instead, or use httpd as a proxy, but I'd rather just leave it the way it is if there's any other option. I think you'd want it on the load balancer. Possibly with additional certs on your backend nodes, if you want HTTPS communication between the load balancer and the Tomcat nodes. Not contradicting anything Daniel is saying, but maybe something to add, and maybe that's the missing part of the original puzzle : If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or response that it is sending back is going to include that port number after the hostname. (even inside the pages, if you use absolute URL links there). So the browser who ultimately receives this, is going to try to talk to port 8443. But that will not work, if your front-end is expecting further requests on port 443, and blocks 8443. Unless in all your Tomcat responses, you arrange to replace any reference to port 8443, by 443, before they reach the browser again. Maybe using a browser plugin like HttpFox, LiveHttpHeaders or Fiddler2 would allow you to see more clearly what is going on there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL redirect problems
TC 7.0.54 / RHEL 6 I have two physical servers, each running an instance of TC. The servers are behind a hardware loadbalancer. IPTables is routing request on 80 to 8080. This seems unnecessary. If you have a hardware load balancer in front of Tomcat, it is the only thing that would ever talk to Tomcat. Thus if you just configure it to go to port 8080 you don't need the iptables rule. I can't imagine it's hurting anything, but just thought I'd mention it. Not at all, it would seem like a better choice than an OS level redirect like iptables. Tomcat runs under a non-root user. All good. I needed to protect an area of our webapp under SSL. Went ahead and installed the cert on each server. I can go directly to each server by IP under SSL and get the cert (with the expected IP doesn't match FQDN warning). You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. Ex: browser - HTTPS - load balancer - HTTP or HTTPS - Tomcat If you put an SSL certificate on your Tomcat servers, that would allow you to secure the connection between your load balancer and Tomcat. Depending on your network and security requirements this may or may not be necessary. I'd say most people don't do this because terminating SSL on the load balancer is sufficient. It just depends on your requirements though. Ok, that makes sense. I think just on the loadbalancer will work. In our configuration, unencrypted traffic between the LB and the servers is subject to minimal risk, and our security requirements aren't critical. But when I go through the loadbalancer I can't access anything under port 8443. I redirected 443 to 8443 on each TC server using IPTables, but still no luck. Is there anything I'm missing? The load balancer is almost certainly listening on port 80 and 443. To test, you'd want to connect to the load balancer on one of those ports. The load balancer would then connect to one of your backend nodes and proxy the request on your behalf. Your browser will not connect directly to the backend nodes (see my point above about not needing the iptables rule), unless you specifically point it to the ip address of one of the backend nodes. Sorry, I'm a bit unclear on this. What method of connecting would let me test? I think you'd want it on the load balancer. Possibly with additional certs on your backend nodes, if you want HTTPS communication between the load balancer and the Tomcat nodes. Dan Thanks so much for the detailed and quick reply. John
Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
By the way, pardon my ignorance, but what's a RAD ? I did look it up in Google, but it comes up with either Rite Aid Corporation or a unit of nuclear radiation.. Deme Carv wrote: Fistlly, thank you both of all for answering. I am very glad for very rapid comments. I attached a file in my original question which tells the jar I have in both situation. I guess it might not be delivered to the forum. I know that there is RAD involved but there are as well apache libraries included and I am sure there are a lot of people in this forum with huge experience in such libraries. I don't think my root cause is related to the Websphere server. I guess that there are some conflict between jars. Even though you might think different, could you at least tell me if you see some conflict in this libraries? The problem arises when apache.xalan.serialize.SerializerToXML run with libraries below. C:\IBM\SDP\runtimes\base_v61\lib C:\Rad\workspace\my_app\WebContent\WEB-INF\lib.eclipseproductactivation.jar activation-impl.jarclasses12.jaraspectjrt.jarcommons-collections.jarbase.jar commons-fileupload.jarbootstrap.jarcommons-io-1.4.jarbsf-engines.jar commons-logging.jarcommandlineutils.jaribmjzos.jarEJBCommandTarget.jar javax.jarffdcSupport.jarjstl.jarhtmlshell.jarjta.jarinstallver.jarjzos.jar installxml.jarlog4j-1.2.14.jariscdeploy.jarmail.jarivblogbr.jar quartz-1.6.0.jarIVTClient.jarquartz-all-1.6.0.jarj2ee.jarspring.jarjacl.jar standard.jarlaunchclient.jarxalan-2.4.1.jarlmproxy.jarxerces-1.4.4.jar mail-impl.jarmarshall.jarnif.jarpc-appext.jarphysicalrep.jarpmirm4arm.jar rrd-appext.jarrsadbutils.jarrsahelpers.jarserviceadapter.jar sib.api.jmsra.rarsib.ra.rarsljc.jarspy-sl.jarspy.jarsqlserver.jarstartup.jar tcljava.jarurlprotocols.jarutil.jarwsatlib.jarwsif-compatb.jar 2014-08-01 9:05 GMT-03:00 Daniel Mikusa dmik...@pivotal.io: On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/sax/ContentHandler;Lorg/apache/xpath/DOMHelperV NoSuchMethodErrors often occur when you have the wrong version of a library on your class path. This happens because your code is looking for one version, that has method X while the library you've included has a different version without method X. I don't know a lot about WebSphere, but I do recall that it ships with an older set of libraries and that it prefers those libraries (it calls this parent first) over ones in the application (it calls this parent last). I've seen cases where switching to parent last mode has resolved similar issues. If that doesn't help, I second André's suggestion to look for help in a more appropriate forum. Dan at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - 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: SSL redirect problems
On 01/08/2014 16:30, Daniel Mikusa wrote: You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. That depends on whether the load-balancer is operating at layer 4 or layer 7. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
Sorry, it is my fault. Rational Application Development. Basicaly it is an IBM version of Eclipse. Let's say, like there is a Spring version of eclipse wich comes with Fabric server easily settled, IBM provides RAD wich has easily setting of Websphere. I guess that I am facing the error because some jar wich comes with RAD or Websphere is conflicting when I am using Xarlan but I am not that experienced in Xarlan so I don't know which I could try remove or update from the previous list. 2014-08-01 12:51 GMT-03:00 André Warnier a...@ice-sa.com: By the way, pardon my ignorance, but what's a RAD ? I did look it up in Google, but it comes up with either Rite Aid Corporation or a unit of nuclear radiation.. Deme Carv wrote: Fistlly, thank you both of all for answering. I am very glad for very rapid comments. I attached a file in my original question which tells the jar I have in both situation. I guess it might not be delivered to the forum. I know that there is RAD involved but there are as well apache libraries included and I am sure there are a lot of people in this forum with huge experience in such libraries. I don't think my root cause is related to the Websphere server. I guess that there are some conflict between jars. Even though you might think different, could you at least tell me if you see some conflict in this libraries? The problem arises when apache.xalan.serialize.SerializerToXML run with libraries below. C:\IBM\SDP\runtimes\base_v61\lib C:\Rad\workspace\my_app\WebContent\WEB-INF\lib. eclipseproductactivation.jar activation-impl.jarclasses12.jaraspectjrt.jarcommons- collections.jarbase.jar commons-fileupload.jarbootstrap.jarcommons-io-1.4.jarbsf-engines.jar commons-logging.jarcommandlineutils.jaribmjzos.jarEJBCommandTarget.jar javax.jarffdcSupport.jarjstl.jarhtmlshell.jarjta. jarinstallver.jarjzos.jar installxml.jarlog4j-1.2.14.jariscdeploy.jarmail.jarivblogbr.jar quartz-1.6.0.jarIVTClient.jarquartz-all-1.6.0.jarj2ee. jarspring.jarjacl.jar standard.jarlaunchclient.jarxalan-2.4.1.jarlmproxy.jarxerces-1.4.4.jar mail-impl.jarmarshall.jarnif.jarpc-appext.jarphysicalrep.jarpmirm4arm.jar rrd-appext.jarrsadbutils.jarrsahelpers.jarserviceadapter.jar sib.api.jmsra.rarsib.ra.rarsljc.jarspy-sl.jarspy. jarsqlserver.jarstartup.jar tcljava.jarurlprotocols.jarutil.jarwsatlib.jarwsif-compatb.jar 2014-08-01 9:05 GMT-03:00 Daniel Mikusa dmik...@pivotal.io: On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/ sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/ sax/ContentHandler;Lorg/apache/xpath/DOMHelperV NoSuchMethodErrors often occur when you have the wrong version of a library on your class path. This happens because your code is looking for one version, that has method X while the library you've included has a different version without method X. I don't know a lot about WebSphere, but I do recall that it ships with an older set of libraries and that it prefers those libraries (it calls this parent first) over ones in the application (it calls this parent last). I've seen cases where switching to parent last mode has resolved similar issues. If that doesn't help, I second André's suggestion to look for help in a more appropriate forum. Dan at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here serializertoxml.flushWriter(); filewriter.write(\n); filewriter.close(); - 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: SSL redirect problems
Not contradicting anything Daniel is saying, but maybe something to add, and maybe that's the missing part of the original puzzle : If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or response that it is sending back is going to include that port number after the hostname. (even inside the pages, if you use absolute URL links there). So the browser who ultimately receives this, is going to try to talk to port 8443. But that will not work, if your front-end is expecting further requests on port 443, and blocks 8443. Unless in all your Tomcat responses, you arrange to replace any reference to port 8443, by 443, before they reach the browser again. Maybe using a browser plugin like HttpFox, LiveHttpHeaders or Fiddler2 would allow you to see more clearly what is going on there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Well, that's the part that seems confusing. Left as default, I would have thought connecting through the LB on 8443 would have worked. Actually I'm still not clear on which part of the chain is having a problem. Originally, I had no iptable redirect - I just added it in the great tradition of programming - try everything and anything until it works. I don't care if the user has to have 8443 in the URL. Just to be clear, you are suggesting that then problem would be the iptables redirect?
Re: SSL redirect problems
On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote: On 01/08/2014 16:30, Daniel Mikusa wrote: You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. That depends on whether the load-balancer is operating at layer 4 or layer 7. Mark Mark, I have to check which layer it's operating at, but does that mean that, depending on the layer, the cert should *not* be on the LB?
Re: COMET End event subtype= null
ok now it is properly configured(I was missing the slash at the end of the tag), but Im still getting null for event subtypes. Any thoughts? On Fri, Aug 1, 2014 at 11:18 AM, Elias Kopsiaftis yemi...@gmail.com wrote: ok looks like i have the configuration of org.apache.catalina.valves.CometConnectionManagerValve wrong. sorry about that. Still have the random disconnect error though On Fri, Aug 1, 2014 at 10:46 AM, Elias Kopsiaftis yemi...@gmail.com wrote: I am developing a COMET application that is primarily based on the example given on the documentation of the chat server. My problem is that when two users connect, the connection held open by the comet servlet is closed. I know this because I am getting END events in my log. The confusing part is, it will randomly fail, and when it does, subtype is null. When I say randomly fail, I mean get the END event when you are not supposed to. Does subtype being null point to anything? This is so frustrating because it fails randomly. I am on Tomcat7 on linux. I can provide more info if its needed
Re: SSL redirect problems
John Smith wrote: Not contradicting anything Daniel is saying, but maybe something to add, and maybe that's the missing part of the original puzzle : If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or response that it is sending back is going to include that port number after the hostname. (even inside the pages, if you use absolute URL links there). So the browser who ultimately receives this, is going to try to talk to port 8443. But that will not work, if your front-end is expecting further requests on port 443, and blocks 8443. Unless in all your Tomcat responses, you arrange to replace any reference to port 8443, by 443, before they reach the browser again. Maybe using a browser plugin like HttpFox, LiveHttpHeaders or Fiddler2 would allow you to see more clearly what is going on there. Well, that's the part that seems confusing. Left as default, I would have thought connecting through the LB on 8443 would have worked. Actually I'm still not clear on which part of the chain is having a problem. Originally, I had no iptable redirect - I just added it in the great tradition of programming - try everything and anything until it works. I don't care if the user has to have 8443 in the URL. Just to be clear, you are suggesting that then problem would be the iptables redirect? No, I am not really going that far. I am suggesting that that may be the kind of thing that is happening, and that you may want to investigate with a browser plugin, that the requests/responses are really what you are expecting. Your initial explanation was a bit confusing and lacking in precise details, as to what the load balancer really does, where IPtables does what, and how your tomcats are configured (re Connectors, and possibly IPtables too). So we're all kind of guessing here, and just trying to give you some tips, to either simplify your setup, or to figure out better what is happening. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL redirect problems
No, I am not really going that far. I am suggesting that that may be the kind of thing that is happening, and that you may want to investigate with a browser plugin, that the requests/responses are really what you are expecting. Your initial explanation was a bit confusing and lacking in precise details, as to what the load balancer really does, where IPtables does what, and how your tomcats are configured (re Connectors, and possibly IPtables too). So we're all kind of guessing here, and just trying to give you some tips, to either simplify your setup, or to figure out better what is happening. Well, lets remove the IP tables. I know the certs work because as I said I can access them directly by going to either server on 8443 directly. The connectors are configured correctly. There's no security info in web.xml. The entire site should be available over SSL. Using Charles, with LB:8443 I get connection refused - without any other particularly useful info in the response.
Re: SSL redirect problems
John Smith wrote: No, I am not really going that far. I am suggesting that that may be the kind of thing that is happening, and that you may want to investigate with a browser plugin, that the requests/responses are really what you are expecting. Your initial explanation was a bit confusing and lacking in precise details, as to what the load balancer really does, where IPtables does what, and how your tomcats are configured (re Connectors, and possibly IPtables too). So we're all kind of guessing here, and just trying to give you some tips, to either simplify your setup, or to figure out better what is happening. Well, lets remove the IP tables. I know the certs work because as I said I can access them directly by going to either server on 8443 directly. The connectors are configured correctly. There's no security info in web.xml. The entire site should be available over SSL. Using Charles, with LB:8443 I get connection refused - without any other particularly useful info in the response. There is no response, since you are not even able to connect to that IP:port. If you are using the IP of the LB, then the LB is not accepting connections on port 8443. You won't get much further, unless you solve that first. But I thought that you wanted your users to access via port 443 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NoSuchMethodError: org/apache/xml/utils/TreeWalker
On Fri, Aug 1, 2014 at 11:58 AM, Deme Carv demec...@gmail.com wrote: Sorry, it is my fault. Rational Application Development. Basicaly it is an IBM version of Eclipse. Let's say, like there is a Spring version of eclipse wich comes with Fabric server easily settled, IBM provides RAD wich has easily setting of Websphere. I guess that I am facing the error because some jar wich comes with RAD or Websphere is conflicting when I am using Xarlan but I am not that experienced in Xarlan so I don't know which I could try remove or update from the previous list. First, please don't top post. The convention adopted on this list is to either reply inline (like this) or at the bottom of requests. Second, maybe try running with the -verbose jvm option? That should show you what classes are loaded and from where they are loaded. Look for the class that is causing the problem and that should let you see if it's loading the one you expect. Dan 2014-08-01 12:51 GMT-03:00 André Warnier a...@ice-sa.com: By the way, pardon my ignorance, but what's a RAD ? I did look it up in Google, but it comes up with either Rite Aid Corporation or a unit of nuclear radiation.. Deme Carv wrote: Fistlly, thank you both of all for answering. I am very glad for very rapid comments. I attached a file in my original question which tells the jar I have in both situation. I guess it might not be delivered to the forum. I know that there is RAD involved but there are as well apache libraries included and I am sure there are a lot of people in this forum with huge experience in such libraries. I don't think my root cause is related to the Websphere server. I guess that there are some conflict between jars. Even though you might think different, could you at least tell me if you see some conflict in this libraries? The problem arises when apache.xalan.serialize.SerializerToXML run with libraries below. C:\IBM\SDP\runtimes\base_v61\lib C:\Rad\workspace\my_app\WebContent\WEB-INF\lib. eclipseproductactivation.jar activation-impl.jarclasses12.jaraspectjrt.jarcommons- collections.jarbase.jar commons-fileupload.jarbootstrap.jarcommons-io-1.4.jarbsf-engines.jar commons-logging.jarcommandlineutils.jaribmjzos.jarEJBCommandTarget.jar javax.jarffdcSupport.jarjstl.jarhtmlshell.jarjta. jarinstallver.jarjzos.jar installxml.jarlog4j-1.2.14.jariscdeploy.jarmail.jarivblogbr.jar quartz-1.6.0.jarIVTClient.jarquartz-all-1.6.0.jarj2ee. jarspring.jarjacl.jar standard.jarlaunchclient.jarxalan-2.4.1.jarlmproxy.jarxerces-1.4.4.jar mail-impl.jarmarshall.jarnif.jarpc-appext.jarphysicalrep.jarpmirm4arm.jar rrd-appext.jarrsadbutils.jarrsahelpers.jarserviceadapter.jar sib.api.jmsra.rarsib.ra.rarsljc.jarspy-sl.jarspy. jarsqlserver.jarstartup.jar tcljava.jarurlprotocols.jarutil.jarwsatlib.jarwsif-compatb.jar 2014-08-01 9:05 GMT-03:00 Daniel Mikusa dmik...@pivotal.io: On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote: I am getting the error from subject when running the below code in Websphere in my RAD. It is very interesting that this code doesn't cause any error in Server. The server runs up Tomcat 6 but I must set the same code to run in Websphere. I have searched for hours in web but I didn't find nothing that I could at least give a try. I attached a pdf with the libs that I found in each place. I guess that it might exist some conflict but I have no idea why it is working in Tomcat but it is not working in Websphere. Error message in browser: Error 500: org/apache/xml/utils/TreeWalker.init(Lorg/xml/ sax/ContentHandler;Lorg/apache/xpath/DOMHelperV Error message in RAD console: java.lang.NoSuchMethodError: org/apache/xml/utils/TreeWalker.init(Lorg/xml/ sax/ContentHandler;Lorg/apache/xpath/DOMHelperV NoSuchMethodErrors often occur when you have the wrong version of a library on your class path. This happens because your code is looking for one version, that has method X while the library you've included has a different version without method X. I don't know a lot about WebSphere, but I do recall that it ships with an older set of libraries and that it prefers those libraries (it calls this parent first) over ones in the application (it calls this parent last). I've seen cases where switching to parent last mode has resolved similar issues. If that doesn't help, I second André's suggestion to look for help in a more appropriate forum. Dan at org.apache.xalan.serialize.SerializerToXML.seriali ze(SerializerToXML.java:2578) org.apache.xalan.serialize.SerializerToXML serializertoxml = new org.apache.xalan.serialize.SerializerToXML(); My code snippet: java.io.FileWriter filewriter = new java.io.FileWriter(file); serializertoxml.setWriter(filewriter); serializertoxml.serialize(node); // the error happens here
Re: SSL redirect problems
On 8/1/2014 12:35 PM, John Smith wrote: No, I am not really going that far. I am suggesting that that may be the kind of thing that is happening, and that you may want to investigate with a browser plugin, that the requests/responses are really what you are expecting. Your initial explanation was a bit confusing and lacking in precise details, as to what the load balancer really does, where IPtables does what, and how your tomcats are configured (re Connectors, and possibly IPtables too). So we're all kind of guessing here, and just trying to give you some tips, to either simplify your setup, or to figure out better what is happening. Well, lets remove the IP tables. I know the certs work because as I said I can access them directly by going to either server on 8443 directly. The connectors are configured correctly. There's no security info in web.xml. The entire site should be available over SSL. Using Charles, with LB:8443 I get connection refused - without any other particularly useful info in the response. Is your LB configured to listen on 8443, or on 443? It won't pick up the port it's supposed to listen on from the TC instances; you have to specify it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL redirect problems
On Fri, Aug 1, 2014 at 11:49 AM, John Smith tomcat.ran...@gmail.com wrote: TC 7.0.54 / RHEL 6 I have two physical servers, each running an instance of TC. The servers are behind a hardware loadbalancer. IPTables is routing request on 80 to 8080. This seems unnecessary. If you have a hardware load balancer in front of Tomcat, it is the only thing that would ever talk to Tomcat. Thus if you just configure it to go to port 8080 you don't need the iptables rule. I can't imagine it's hurting anything, but just thought I'd mention it. Not at all, it would seem like a better choice than an OS level redirect like iptables. Tomcat runs under a non-root user. All good. I needed to protect an area of our webapp under SSL. Went ahead and installed the cert on each server. I can go directly to each server by IP under SSL and get the cert (with the expected IP doesn't match FQDN warning). You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. Ex: browser - HTTPS - load balancer - HTTP or HTTPS - Tomcat If you put an SSL certificate on your Tomcat servers, that would allow you to secure the connection between your load balancer and Tomcat. Depending on your network and security requirements this may or may not be necessary. I'd say most people don't do this because terminating SSL on the load balancer is sufficient. It just depends on your requirements though. Ok, that makes sense. I think just on the loadbalancer will work. In our configuration, unencrypted traffic between the LB and the servers is subject to minimal risk, and our security requirements aren't critical. But when I go through the loadbalancer I can't access anything under port 8443. I redirected 443 to 8443 on each TC server using IPTables, but still no luck. Is there anything I'm missing? The load balancer is almost certainly listening on port 80 and 443. To test, you'd want to connect to the load balancer on one of those ports. The load balancer would then connect to one of your backend nodes and proxy the request on your behalf. Your browser will not connect directly to the backend nodes (see my point above about not needing the iptables rule), unless you specifically point it to the ip address of one of the backend nodes. Sorry, I'm a bit unclear on this. What method of connecting would let me test? To test, you would just open your browser and connect to the load balancer. For example, put http://you-lb-dns-name/ and for SSL https://your-lb-dns-name. If everything works, you'll get a response from your application. Behind the scenes, this will send a request to the load balancer, either via HTTP or HTTPS. If you're load balancer is functioning at layer 7, like Mark mentioned, it'll get the HTTP request and proxy this to one of your backend servers. The backend server will then process the request and return it to the load balancer. The load balancer will then return the response to your browser. As your testing keep this process in mind. If you encounter a problem just try to break down the flow from your browser to the server and back. If you look at the request at each hop through this process, you can often find where things went wrong. For example, did the request hit the LB? If not, maybe we have a firewall issue or ports are configured right. If so, did it hit one of the backend servers? If not, maybe there's a config issue in the lb. If it did, what response did it get? A 4xx / 5xx error, ok something went wrong on the backend, need to investigate the logs there for more details. Hope that helps to clarify. Dan I think you'd want it on the load balancer. Possibly with additional certs on your backend nodes, if you want HTTPS communication between the load balancer and the Tomcat nodes. Dan Thanks so much for the detailed and quick reply. John
Re: SSL redirect problems
As your testing keep this process in mind. If you encounter a problem just try to break down the flow from your browser to the server and back. If you look at the request at each hop through this process, you can often find where things went wrong. For example, did the request hit the LB? If not, maybe we have a firewall issue or ports are configured right. If so, did it hit one of the backend servers? If not, maybe there's a config issue in the lb. If it did, what response did it get? A 4xx / 5xx error, ok something went wrong on the backend, need to investigate the logs there for more details. Hope that helps to clarify. Dan Dan, It did. It was one of those cases where the simplest answer was assumed but not tested. The loadbalancer was not listening on 443 or 8443. I was able to have it redirect 443 to 8443 successfully. I also took your advice and redirected 80 to 8080 instead of using iptables. Thanks for your help. So many knowledgeable people on here. John
Re: SSL redirect problems
Is your LB configured to listen on 8443, or on 443? It won't pick up the port it's supposed to listen on from the TC instances; you have to specify it. Nailed it. Simplest solution, I didn't even consider it. Thanks, John
Re: SSL redirect problems
There is no response, since you are not even able to connect to that IP:port. If you are using the IP of the LB, then the LB is not accepting connections on port 8443. You won't get much further, unless you solve that first. But I thought that you wanted your users to access via port 443 ? Thanks, This was the problem. So simple I should have looked there first. Facepalms. I was able to redirect 443 to 8443 on the LB with success.
Re: SSL redirect problems
On 8/1/2014 1:33 PM, John Smith wrote: Is your LB configured to listen on 8443, or on 443? It won't pick up the port it's supposed to listen on from the TC instances; you have to specify it. Nailed it. Simplest solution, I didn't even consider it. Thanks, John Thanks for letting us know what the issue was; many people never come back and tell us what fixed it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL redirect problems
On 01/08/2014 17:06, John Smith wrote: On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote: On 01/08/2014 16:30, Daniel Mikusa wrote: You probably want the SSL certificate installed on your hardware load balancer. End client's browsers are going to connect to the hardware load balancer, not Tomcat. Thus you'd want the certificate there so your end users can benefit from it. That depends on whether the load-balancer is operating at layer 4 or layer 7. Mark Mark, I have to check which layer it's operating at, but does that mean that, depending on the layer, the cert should *not* be on the LB? TLS is layer 5 so if the LB is operating at layer 4 it can't host the cert. Some LBs can operate at layer 5 so it will depend on your LB and/or its configuration. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Restricting SSL access within webapp
In my webapp there's a directory '/admin' that's protected under SSL. Users are forced to use SSL via a security constraint in web.xml. It works great. As mentioned in the docs and other places, it would be good to prevent SSL everywhere else on the site, but I searched around and couldn't find anything that works.I tried adding another security constraint with transport guarantee set to NONE for url-pattern '/*' but it didn't prevent https access to the site as a whole. What's the correct way to selectively restrict https to only one area of a webapp? TIA, John
Re: SSL redirect problems
Thanks for letting us know what the issue was; many people never come back and tell us what fixed it. My pleasure. This list is awesome.
Re: SSL redirect problems
TLS is layer 5 so if the LB is operating at layer 4 it can't host the cert. Some LBs can operate at layer 5 so it will depend on your LB and/or its configuration. Mark I see. That's good to know. The LB is at 7.
RE: Restricting SSL access within webapp
From: John Smith [mailto:tomcat.ran...@gmail.com] Subject: Restricting SSL access within webapp What's the correct way to selectively restrict https to only one area of a webapp? Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: John Smith [mailto:tomcat.ran...@gmail.com] Subject: Restricting SSL access within webapp What's the correct way to selectively restrict https to only one area of a webapp? Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion? - Chuck From the docs: Also, while the SSL protocol was designed to be as efficient as securely possible, encryption/decryption is a computationally expensive process from a performance standpoint. It is not strictly necessary to run an entire web application over SSL, and indeed a developer can pick and choose which pages require a secure connection and which do not. For a reasonably busy site, it is customary to only run certain pages under SSL, namely those pages where sensitive information could possibly be exchanged. Unfortunately how to do this isn't explained. I might use a filter. Our site handles 500,000 visitors a day on two TC instances. Believe me, I need to consider performance costs.
Re: Restricting SSL access within webapp
Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion? I'm with Chuck on that one. From the docs: Also, while the SSL protocol was designed to be as efficient as securely possible, encryption/decryption is a computationally expensive process from a performance standpoint. Well, I'll say that I find it rather irritating, when on my dial-up (YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless you're signed on, and explicitly opt out of it. But then again, there are a LOT of web sites that are immensely bandwidth-intensive, and actively hostile to older browsers (that may nonetheless be the newest browsers available for a given combination of hardware and OS), all for no good reason (other than adware and spyware), and SSL is only a small part of that unnecessary waste of bandwidth. But that said, I think that when there's no overriding security reason to require SSL, and no overriding bandwidth limitation reason to prohibit it, it should be the user's call on whether to use HTTP or HTTPS. -- JHHL _ ( ) X / \ ASCII ribbon for plain text email - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 8/1/14, 5:43 PM, John Smith wrote: On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: John Smith [mailto:tomcat.ran...@gmail.com] Subject: Restricting SSL access within webapp What's the correct way to selectively restrict https to only one area of a webapp? Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion? - Chuck From the docs: Also, while the SSL protocol was designed to be as efficient as securely possible, encryption/decryption is a computationally expensive process from a performance standpoint. It is not strictly necessary to run an entire web application over SSL, and indeed a developer can pick and choose which pages require a secure connection and which do not. For a reasonably busy site, it is customary to only run certain pages under SSL, namely those pages where sensitive information could possibly be exchanged. Unfortunately how to do this isn't explained. I might use a filter. Our site handles 500,000 visitors a day on two TC instances. Believe me, I need to consider performance costs. You'd have to determine which URL patterns are okay for dropping HTTPS and then do a protocol-changing redirect. You can do this with a custom Filter, or you might even be able to use url-rewrite to do the job... I've never tried to configure that to switch protocols and do a self-redirect. Writing the code yourself should be easy, but you should probably give url-rewrite a try first. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT3A+5AAoJEBzwKT+lPKRYTVQP/0wfHnoTIn0KAagCY7zRUlml jbWW9GHtOpxt3ZV7BxVdAkC4VipTm/apiTQnbPOMpqzzoQS4fuw2ccc837M7u8lW ZpqVN5yvaQPe21wGUuEWT79wi0gXZhZe6eUb2B+PHcqwWz8DPYLAedGYYCEsZAYb Rtrztb9HnVRSYaiQJOr3pvzmrkuoOT8db1qhuggtOzsSFXDcTcQzYLF3iaK99cDc WkZlOsbwV4dpMARqfrKsM0b8obUXS96qjjB4zWtmczp12vjhtYQI9w/I1lTSKnDl L26DcCnoDJIi3wIY/Omm6sD/0e1BmHfC+2Pxv84HVIvGgRjG0sOLCDIPxFLfw6C4 LlomNmdPzFlwebkTjUc5hC3SQoNk5+a3LM6TFiouf4vw7wnpsNhyvt9odU4bGUv3 2eSiS9n1AMP/Zrb/6Ks92THXY1XzH17a7jCMXpwDxSYqXnYsEeUlB+oPLadkBe38 bMm5P9IXidccm0Fuvha6I042Xd/W++siA+fK3OChEI1FsDgrIhXQmmMRn39a7GOV GmX390FMxfUfxqQMrkgaKYqwYhTzS9rnhy0shZyOsnZvTASJU8X6qi2BcLE8HEZL 4OKWWfnHDf744NM18fie6ltCjs2LfalyyU8dm741j6CYBraBd9dlgGEYOz58kOAx XpVVogN5dbaL3erz4or+ =udcL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
On Fri, Aug 1, 2014 at 1:55 PM, John Smith tomcat.ran...@gmail.com wrote: In my webapp there's a directory '/admin' that's protected under SSL. Users are forced to use SSL via a security constraint in web.xml. It works great. I would also agree with Chuck and James. Can you not move this admin app to another instance of Tomcat? Why dangle it out there on the same server that has all your other non-SSL required webapps? Just asking. leo
Re: Restricting SSL access within webapp
On 8/1/2014 6:06 PM, James H. H. Lampert wrote: Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion? I'm with Chuck on that one. From the docs: Also, while the SSL protocol was designed to be as efficient as securely possible, encryption/decryption is a computationally expensive process from a performance standpoint. Well, I'll say that I find it rather irritating, when on my dial-up (YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless you're signed on, and explicitly opt out of it. But then again, there are a LOT of web sites that are immensely bandwidth-intensive, and actively hostile to older browsers (that may nonetheless be the newest browsers available for a given combination of hardware and OS), all for no good reason (other than adware and spyware), and SSL is only a small part of that unnecessary waste of bandwidth. But that said, I think that when there's no overriding security reason to require SSL, and no overriding bandwidth limitation reason to prohibit it, it should be the user's call on whether to use HTTP or HTTPS. I don't think the problem is so much bandwidth as it is server CPU. Encryption and decryption are very cpu-intensive tasks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
On 8/1/14 4:54 PM, David Kerber wrote: I don't think the problem is so much bandwidth as it is server CPU. Encryption and decryption are very cpu-intensive tasks. Not to mention client CPU. (Let's face it, if somebody's on dial-up, they're probably on an old, slow box, too. Like my G4 bionic desk lamp iMac.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
