DO NOT REPLY [Bug 40050] - context XML file deleted when path is not readable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 40050] - context XML file deleted when path is not readable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 40050] New: - context XML file deleted when path is not readable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Patch to override request.getRemoteAddr if behind a reverse proxy

This is a question for the user list, it might be better for you to take the inquiries there, and you shouldn't need to hack tomcat for something like this. Simply create a filter, that wraps your HttpServletRequest in a HttpServletRequestWrapper, worst case you could create Valve that does it

Patch to override request.getRemoteAddr if behind a reverse proxy

Hi I'm totally new to hacking Tomcat, so excuse if I'm not following the proper procedure, but needed to do this for our site that has a Tomcat behind Apache (mod_jk), that sits behind a reverse proxy load balancer. The idea is basically to not use the TCP endpoint of Apache (which will always poi

Re: [TC6] Cluster and storeconfig

Hi Remy and Filip, overwhelmed is much more correct than uncomfortable. I think looking at how much work Filip has put into it since it's beginnings, it was good to not immediately change the default implementation for TC 5.5 when Filip started. As Filip thinks it's ready for TC 6, I will happily

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

Rainer Jung wrote: I think Mladen and I both want people to move to mod_proxy_*. Mladen already offered help and httpd-dev for porting mod_jk improvements to mod_proxy_* and I definitely want to join him in that. But first I need to manage the pending mod_jk release, something we are right now do

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

I think Mladen and I both want people to move to mod_proxy_*. Mladen already offered help and httpd-dev for porting mod_jk improvements to mod_proxy_* and I definitely want to join him in that. But first I need to manage the pending mod_jk release, something we are right now doing. I don't know mo

DO NOT REPLY [Bug 37869] - Cannot obtain client certificate with SSL / client certificate authentication using APR components

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

mod_jk 1.2.17 vs. mod_proxy_ajp

What is the plan for mod_proxy_ajp catching up with all the improvements in the latest mod_jk? As I understand it, mod_proxy_ajp is currently lagging, which is understandable -- one or the other has to. I'm just wanting to get some grasp of the probable/planned timeframe for mod_proxy_ajp cat

Re: Mod_jk : function maintain()

Jean-frederic Clere wrote: If you finish your maintenance module then it'll be his responsibility to make a heartbeat independent of the request, on the regular intervals. Sure I need an extra program to make a real heartbeat but I still still don't see how I could close a socket in a httpd s

Re: Mod_jk : function maintain()

Mladen Turk wrote: Jean-frederic Clere wrote: Rainer Jung wrote: It's called once a minute (at least if a request comes in) to be able to clean up things not directly related to the actual request, like closing idle connections. Something to add to mod_proxy probably. If you finish