Re: Configuration of Default Servlet for a single Container?
On 31/01/14 13:27, Brian Burch wrote: On 31/01/14 12:48, Mark Thomas wrote: On 31/01/2014 12:42, Brian Burch wrote: Have I overlooked a configuration trick that would allow me to use the webapp without a symlink, but still have the Default Servlet access external static content as if it were internal? http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes aliases? Thanks very much, as always, for your rapid response. I will follow that link with interest. If you switch to Tomcat 8, you get a cleaner implementation and much more control with the new resources implementation. I'll get back to you if I don't understand, but otherwise, thanks very much, This task finally arrived near the top of my list. I started by looking at org.apache.catalina.core.TestStandardContextAliases, which was very helpful. So was the javadoc for org.apache.catalina.core.StandardContext.setAliases(String). I then thought about extending my existing logic to support both the existing internal and the new external directory trees. I thought I had a viable approach, but have hit an implementation issue that does not seem to have an elegant, lightweight solution. JSPWiki is not intended to be dependent on tomcat, so it should only use services defined in the sevlet api. My existing plugin currently follows this constraint, and I would like to do the same with my enhancement. Unfortunately, the setAliases method is not inherited from javax.servlet.ServletContext and I couldn't find any reference to aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a tomcat-only feature? If it is tomcat-only, then my enhancement would not be available under any other flavour of webapp container. Worse still, I can't simply cast the execution Context to a StandardContext. I'll have to write introspection code to avoid a ClassNotFoundException when the plugin is loaded during deployment of the JSPWiki war... Does that sound about right, Mark? I am prepared to go ahead implementing a tomcat-only feature, but I would like to be sure it is the only or best solution before doing a lot of work. Thanks... Brian Brian Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuration of Default Servlet for a single Container?
On 22/03/2014 12:25, Brian Burch wrote: On 31/01/14 13:27, Brian Burch wrote: On 31/01/14 12:48, Mark Thomas wrote: On 31/01/2014 12:42, Brian Burch wrote: Have I overlooked a configuration trick that would allow me to use the webapp without a symlink, but still have the Default Servlet access external static content as if it were internal? http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes aliases? Thanks very much, as always, for your rapid response. I will follow that link with interest. If you switch to Tomcat 8, you get a cleaner implementation and much more control with the new resources implementation. I'll get back to you if I don't understand, but otherwise, thanks very much, This task finally arrived near the top of my list. I started by looking at org.apache.catalina.core.TestStandardContextAliases, which was very helpful. So was the javadoc for org.apache.catalina.core.StandardContext.setAliases(String). I then thought about extending my existing logic to support both the existing internal and the new external directory trees. I thought I had a viable approach, but have hit an implementation issue that does not seem to have an elegant, lightweight solution. JSPWiki is not intended to be dependent on tomcat, so it should only use services defined in the sevlet api. My existing plugin currently follows this constraint, and I would like to do the same with my enhancement. Unfortunately, the setAliases method is not inherited from javax.servlet.ServletContext and I couldn't find any reference to aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a tomcat-only feature? Correct. Worse still, that API changed completely between Tomcat 7 and Tomcat 8. If it is tomcat-only, then my enhancement would not be available under any other flavour of webapp container. Worse still, I can't simply cast the execution Context to a StandardContext. I'll have to write introspection code to avoid a ClassNotFoundException when the plugin is loaded during deployment of the JSPWiki war... Does that sound about right, Mark? I'm afraid so. I am prepared to go ahead implementing a tomcat-only feature, but I would like to be sure it is the only or best solution before doing a lot of work. Given the work that is likely to be involved I think you are likely to be better off writing your own default servlet. That will be container neutral. I'd hope that Servlet 3.2 will include some form of the aliases feature but it is not certain. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuration of Default Servlet for a single Container?
On 22/03/14 13:10, Martin Gainty wrote: Hi Brian I *think* what youre looking for in JSPWiki Page *Aliases* located here: Thanks for spending time thinking about my question, Martin. Unfortunately, Mark snipped out my original description of the problem and I didn't put it back in my reply. The JSPWiki Page Alias feature is not relevant to the problem I was trying to solve. http://www.ecyrd.com/JSPWiki/wiki/PageAlias That is the OLD JSPWiki web site, which was frozen several months ago and is now read-only. There was some discussion about taking it completely offline in case it confused people, but in the end the devs decided to keep it online as a historical archive because the new web site does not have the same content. JSPWiki has now been adopted as an apache project, and its new web site is here: https://jspwiki-wiki.apache.org/ The PageAlias page no longer exists on the new wiki. I'm sorry to say I have no idea whether the feature was lost in conversion to an apache project - a lot of contributed code simply will not work until it is changed to use the new project package names. http://tomcat.apache.org/whichversion.html Tomcat 7 supports Servlet Spec 3.x but Tomcat 6 now conforms to Servlet Spec 2.5 ...since Servlet-Spec-2.5 is supported by JSPWiki http://www.ecyrd.com/JSPWiki/wiki/JSPWikiDownload you *should* be ok implementing JSPWiki with TC 6 I am using tomcat 7.0.52 on ubuntu linux i386 and openjdk7. I was referring to the servlet 3.0 docs. The latest download for JSPWiki is at: http://www.apache.org/dyn/closer.cgi/jspwiki The latest version is 2.10, but I am working against the latest trunk. Brian HTH, Martin __ Date: Sat, 22 Mar 2014 12:25:38 + From: br...@pingtoo.com To: users@tomcat.apache.org Subject: Re: Configuration of Default Servlet for a single Container? On 31/01/14 13:27, Brian Burch wrote: On 31/01/14 12:48, Mark Thomas wrote: On 31/01/2014 12:42, Brian Burch wrote: Have I overlooked a configuration trick that would allow me to use the webapp without a symlink, but still have the Default Servlet access external static content as if it were internal? http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes aliases? Thanks very much, as always, for your rapid response. I will follow that link with interest. If you switch to Tomcat 8, you get a cleaner implementation and much more control with the new resources implementation. I'll get back to you if I don't understand, but otherwise, thanks very much, This task finally arrived near the top of my list. I started by looking at org.apache.catalina.core.TestStandardContextAliases, which was very helpful. So was the javadoc for org.apache.catalina.core.StandardContext.setAliases(String). I then thought about extending my existing logic to support both the existing internal and the new external directory trees. I thought I had a viable approach, but have hit an implementation issue that does not seem to have an elegant, lightweight solution. JSPWiki is not intended to be dependent on tomcat, so it should only use services defined in the sevlet api. My existing plugin currently follows this constraint, and I would like to do the same with my enhancement. Unfortunately, the setAliases method is not inherited from javax.servlet.ServletContext and I couldn't find any reference to aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a tomcat-only feature? If it is tomcat-only, then my enhancement would not be available under any other flavour of webapp container. Worse still, I can't simply cast the execution Context to a StandardContext. I'll have to write introspection code to avoid a ClassNotFoundException when the plugin is loaded during deployment of the JSPWiki war... Does that sound about right, Mark? I am prepared to go ahead implementing a tomcat-only feature, but I would like to be sure it is the only or best solution before doing a lot of work. Thanks... Brian Brian Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: [Bug 56301] Websockets not working after 8.0.0-RC10
Hi, this issue concerns the tomcat-embed server, (likely also the normal tomcat server) after version 8.0.1, websockets can't be estblished like before. I tried from a simple websocket example (standard java websocket implemented in tomcat8 http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html) and noticed it from my project https://github.com/n11/mongo-cli-java, working untill apache version 8.0.0-RC10 (see pom.xml) It seems there's a breaking change between 8.0.0-RC10 and 8.0.1 screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423 2014-03-22 13:15 GMT+01:00 bugzi...@apache.org: https://issues.apache.org/bugzilla/show_bug.cgi?id=56301 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mark Thomas ma...@apache.org --- This looks like a configuration problem. Bugzilla is not a support forum. Please use the Tomcat Users mailing list. -- You are receiving this mail because: You reported the bug.
help with setting up proxy
Hi, I am trying to configure Apache Tomcat as a proxy server. Below are the details of what I am trying to do. We have a JBoss running on a server with address 192.168.10.x. JBoss server is connected to bunch of other servers. All the servers are on the same subnet and are configured with 192.168.10.x addresses. I am trying to access my web application running on jboss from the external machine. External inteface of JBoss server is 172.x.x.x address. My web application has some links which launches urls from other connected servers on internal 192.168.10.x network. I cant get those urls directly from external machine using 172.x.x.x address. To address this issue I am planning to set up Apache proxy on my internal network and use proxy PAC file on browser to redirect all url request to internal network 192.168.10.x to the proxy. I have the Proxy PAC file setup correctly but I am not sure how to setup apache to forward all the request to appropriate server. e.g. request for 192.168.10.101\test.html should go to that server and request for 192.168.10.102\test.html should go to that server I hope I am not confusing everybody. thanks, -Hardik
Re: help with setting up proxy
On Sat, Mar 22, 2014 at 9:18 AM, Hardik Vaishnav hardikvaish...@gmail.com wrote: I am trying to configure Apache Tomcat as a proxy server. I hope I am not confusing everybody. I think perhaps you are confusing yourself. Tomcat has no intrinsic proxy server capability to configure. Are you thinking of the Apache httpd server? -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuration of Default Servlet for a single Container?
On 22/03/14 14:05, Mark Thomas wrote: On 22/03/2014 12:25, Brian Burch wrote: On 31/01/14 13:27, Brian Burch wrote: On 31/01/14 12:48, Mark Thomas wrote: On 31/01/2014 12:42, Brian Burch wrote: Have I overlooked a configuration trick that would allow me to use the webapp without a symlink, but still have the Default Servlet access external static content as if it were internal? http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes aliases? Thanks very much, as always, for your rapid response. I will follow that link with interest. If you switch to Tomcat 8, you get a cleaner implementation and much more control with the new resources implementation. I'll get back to you if I don't understand, but otherwise, thanks very much, This task finally arrived near the top of my list. I started by looking at org.apache.catalina.core.TestStandardContextAliases, which was very helpful. So was the javadoc for org.apache.catalina.core.StandardContext.setAliases(String). I then thought about extending my existing logic to support both the existing internal and the new external directory trees. I thought I had a viable approach, but have hit an implementation issue that does not seem to have an elegant, lightweight solution. JSPWiki is not intended to be dependent on tomcat, so it should only use services defined in the sevlet api. My existing plugin currently follows this constraint, and I would like to do the same with my enhancement. Unfortunately, the setAliases method is not inherited from javax.servlet.ServletContext and I couldn't find any reference to aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a tomcat-only feature? Correct. Worse still, that API changed completely between Tomcat 7 and Tomcat 8. If it is tomcat-only, then my enhancement would not be available under any other flavour of webapp container. Worse still, I can't simply cast the execution Context to a StandardContext. I'll have to write introspection code to avoid a ClassNotFoundException when the plugin is loaded during deployment of the JSPWiki war... Does that sound about right, Mark? I'm afraid so. I am prepared to go ahead implementing a tomcat-only feature, but I would like to be sure it is the only or best solution before doing a lot of work. Given the work that is likely to be involved I think you are likely to be better off writing your own default servlet. That will be container neutral. I had not thought of that approach... are you sure it would be helpful? Surely I couldn't do anything more than is already done by the DefaultServlet, which I implicitly use to serve up the JPG and PNG files? I don't immediately see how rolling my own would get me nearer than the DefaultServlet, i.e. allow me to have access to resources outside the webapp container in an OS-neutral manner. Did you mean: a) derive the absolute path to the image file (I can do that already). b) create a File to the resource (which is outside the container). c) read the contents and process the metadata of the file. d) deal with any security issues not handled by the file system permissions mechanism. e) deliver it to the HTTP client. That doesn't sound like an easy option to me! I'd hope that Servlet 3.2 will include some form of the aliases feature but it is not certain. Thanks for working through my question so carefully, Mark. As usual, your accurate and helpful advice is very valuable and has saved me a lot of unproductive work. Regards, Brian Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help with setting up proxy
Sorry my bad. I am talking about Apache httpd server. On Mar 22, 2014 12:29 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Sat, Mar 22, 2014 at 9:18 AM, Hardik Vaishnav hardikvaish...@gmail.com wrote: I am trying to configure Apache Tomcat as a proxy server. I hope I am not confusing everybody. I think perhaps you are confusing yourself. Tomcat has no intrinsic proxy server capability to configure. Are you thinking of the Apache httpd server? -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug 56301] Websockets not working after 8.0.0-RC10
On 22/03/2014 16:17, Cyril Auburtin wrote: Hi, this issue concerns the tomcat-embed server, (likely also the normal tomcat server) after version 8.0.1, websockets can't be estblished like before. I tried from a simple websocket example (standard java websocket implemented in tomcat8 http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html) and noticed it from my project https://github.com/n11/mongo-cli-java, working untill apache version 8.0.0-RC10 (see pom.xml) It seems there's a breaking change between 8.0.0-RC10 and 8.0.1 screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423 Which indicates your WebSocket request received a 404 response so this isn't a WebSocket problem at all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Effects of turning off sendFile in the NIO connector
What effect would setting useSendfile=false have on a web application using the NIO connector? I'm asking because I may want to use gzip compression in the connector. The docs state: *There is a tradeoff between using compression (saving your bandwidth) and using the sendfile feature (saving your CPU cycles). If the connector supports the sendfile feature, e.g. the NIO connector, using sendfile will take precedence over compression. The symptoms will be that static files greater that 48 Kb will be sent uncompressed.* It's trivial that adding compression uses CPU cycles, but does that imply that turning sendFile off even without enabling compression would increase CPU cycles? It's worth mentioning that the site serves a large (8mg) SWF file. I believe that was one of the pluses of NIO/sendFile, that it was good with sending large files under heavy traffic? We also only really need compression on XML data, the site has minimal HTML, SWF's don't really benefit from gzip and some binary data we send back and forth is already compressed. I could manually implement compression on XML at the application level and within the SWF, if turning off sendFile will have negative consequences. Tomcat 7.0.42 RHEL6 ~4T outbound traffic/day Best, John
Re: Configuration of Default Servlet for a single Container?
On 22/03/2014 16:36, Brian Burch wrote: On 22/03/14 14:05, Mark Thomas wrote: On 22/03/2014 12:25, Brian Burch wrote: On 31/01/14 13:27, Brian Burch wrote: On 31/01/14 12:48, Mark Thomas wrote: On 31/01/2014 12:42, Brian Burch wrote: Have I overlooked a configuration trick that would allow me to use the webapp without a symlink, but still have the Default Servlet access external static content as if it were internal? http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes aliases? Thanks very much, as always, for your rapid response. I will follow that link with interest. If you switch to Tomcat 8, you get a cleaner implementation and much more control with the new resources implementation. I'll get back to you if I don't understand, but otherwise, thanks very much, This task finally arrived near the top of my list. I started by looking at org.apache.catalina.core.TestStandardContextAliases, which was very helpful. So was the javadoc for org.apache.catalina.core.StandardContext.setAliases(String). I then thought about extending my existing logic to support both the existing internal and the new external directory trees. I thought I had a viable approach, but have hit an implementation issue that does not seem to have an elegant, lightweight solution. JSPWiki is not intended to be dependent on tomcat, so it should only use services defined in the sevlet api. My existing plugin currently follows this constraint, and I would like to do the same with my enhancement. Unfortunately, the setAliases method is not inherited from javax.servlet.ServletContext and I couldn't find any reference to aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a tomcat-only feature? Correct. Worse still, that API changed completely between Tomcat 7 and Tomcat 8. If it is tomcat-only, then my enhancement would not be available under any other flavour of webapp container. Worse still, I can't simply cast the execution Context to a StandardContext. I'll have to write introspection code to avoid a ClassNotFoundException when the plugin is loaded during deployment of the JSPWiki war... Does that sound about right, Mark? I'm afraid so. I am prepared to go ahead implementing a tomcat-only feature, but I would like to be sure it is the only or best solution before doing a lot of work. Given the work that is likely to be involved I think you are likely to be better off writing your own default servlet. That will be container neutral. I had not thought of that approach... are you sure it would be helpful? Surely I couldn't do anything more than is already done by the DefaultServlet, which I implicitly use to serve up the JPG and PNG files? I don't immediately see how rolling my own would get me nearer than the DefaultServlet, i.e. allow me to have access to resources outside the webapp container in an OS-neutral manner. Did you mean: a) derive the absolute path to the image file (I can do that already). b) create a File to the resource (which is outside the container). c) read the contents and process the metadata of the file. d) deal with any security issues not handled by the file system permissions mechanism. e) deliver it to the HTTP client. That doesn't sound like an easy option to me! Actually, you may be right as the default servlet taps into Tomcat's internals. You'd need to recreate that. My thinking was start with the default servlet code and extend it to look in external locations as well. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug 56301] Websockets not working after 8.0.0-RC10
Hi, thanks for your reply please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426 with the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378) and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with tomcat 8.0.0-RC10 There's clearly a reply in the latter case. the version is the only thing changed between the 2 screenshots, I carefully did mvn clean too the code is here https://github.com/n11/mongo-cli-java it runs very simply with tomcat embedded that you may know well 2014-03-22 19:20 GMT+01:00 Mark Thomas ma...@apache.org: On 22/03/2014 16:17, Cyril Auburtin wrote: Hi, this issue concerns the tomcat-embed server, (likely also the normal tomcat server) after version 8.0.1, websockets can't be estblished like before. I tried from a simple websocket example (standard java websocket implemented in tomcat8 http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html) and noticed it from my project https://github.com/n11/mongo-cli-java, working untill apache version 8.0.0-RC10 (see pom.xml) It seems there's a breaking change between 8.0.0-RC10 and 8.0.1 screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423 Which indicates your WebSocket request received a 404 response so this isn't a WebSocket problem at all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug 56301] Websockets not working after 8.0.0-RC10
Here is the example of what I am trying to do. JBoss Webserver Private IP : 192.168.10.100 JBoss Webserver Public IP 172.x.x.x Server connected to Jboss: 192.168.10.101 192.168.10.102 If I am on the Jboss machine I can access 192.168.10.101\abc\test.html If I am outside the network its not possible to access URL 192.168.10.101\abc\test.html To solve the problem I have PAC file as a proxy for my browser which redirect all request for 192.168.10.101 address to apache httpd proxy server which sits inside the (192.168.x.x) network. Upto this point everything works OK. Request comes to Apache httpd server but it is not able to pass the url as is to 192.168.10.101\abc\test.html and return the response back to the client. thanks, -Hardik On Sat, Mar 22, 2014 at 3:15 PM, Cyril Auburtin cyril.aubur...@gmail.comwrote: Hi, thanks for your reply please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426 with the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378) and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with tomcat 8.0.0-RC10 There's clearly a reply in the latter case. the version is the only thing changed between the 2 screenshots, I carefully did mvn clean too the code is here https://github.com/n11/mongo-cli-java it runs very simply with tomcat embedded that you may know well 2014-03-22 19:20 GMT+01:00 Mark Thomas ma...@apache.org: On 22/03/2014 16:17, Cyril Auburtin wrote: Hi, this issue concerns the tomcat-embed server, (likely also the normal tomcat server) after version 8.0.1, websockets can't be estblished like before. I tried from a simple websocket example (standard java websocket implemented in tomcat8 http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html) and noticed it from my project https://github.com/n11/mongo-cli-java, working untill apache version 8.0.0-RC10 (see pom.xml) It seems there's a breaking change between 8.0.0-RC10 and 8.0.1 screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423 Which indicates your WebSocket request received a 404 response so this isn't a WebSocket problem at all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help with setting up proxy
Here is the example of what I am trying to do. JBoss Webserver Private IP : 192.168.10.100 JBoss Webserver Public IP 172.x.x.x Server connected to Jboss: 192.168.10.101 192.168.10.102 If I am on the Jboss machine I can access 192.168.10.101\abc\test.html If I am outside the network its not possible to access URL 192.168.10.101\abc\test.html To solve the problem I have PAC file as a proxy for my browser which redirect all request for 192.168.10.101 address to apache httpd proxy server which sits inside the (192.168.x.x) network. Upto this point everything works OK. Request comes to Apache httpd server but it is not able to pass the url as is to 192.168.10.101\abc\test.html and return the response back to the client. thanks, -Hardik On Sat, Mar 22, 2014 at 2:04 PM, Hardik Vaishnav hardikvaish...@gmail.comwrote: Sorry my bad. I am talking about Apache httpd server. On Mar 22, 2014 12:29 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Sat, Mar 22, 2014 at 9:18 AM, Hardik Vaishnav hardikvaish...@gmail.com wrote: I am trying to configure Apache Tomcat as a proxy server. I hope I am not confusing everybody. I think perhaps you are confusing yourself. Tomcat has no intrinsic proxy server capability to configure. Are you thinking of the Apache httpd server? -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
