RE: mod_jk, mod_jk2 URI spaces
Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). Does that make any sense? After I read my mail, it doesn't make sense even for me :) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
On Wed, 31 Jul 2002, Mladen Turk wrote: Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). Does that make any sense? After I read my mail, it doesn't make sense even for me :) I actually understood the orginal mail, it's not that bad ( i.e. I've written worse messages :-) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). +1 The goal is to have tomcat serve dynamic content and apache static content, respecting as strictly as possible the web.xml semantic. Anything that helps that goal is good. However, I would like to see this in jk2 - JkMount is going to be deprecated and there is the issue of supporting multiple servers ( it won't be trivial to fix iis/nes in jk1.2 to support the same thing ). Plus jk1.2 is stable and close to a release. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
On Wed, 2002-07-31 at 23:55, Mladen Turk wrote: Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. After I read my mail, it doesn't make sense even for me :) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). I see your point here. You are running a setup where anything not specifically targeted for Apache goes to Tomcat. As long as this doesn't affect current situation (and I don't see how it would) where I can set up that Tomcat only gets what's not specifically targeted for Apache, I'm +1. This would make mod_jk configuration really flexible. Bojan PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
-Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 12:00 AM To: Tomcat Dev List Subject: RE: mod_jk, mod_jk2 URI spaces This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. Yes something like that. This will allow to serve the compiled applications and still deliver the static context from those locations, overlaying Apache URI space (if set) over already resolved TC uri space. Well, at least the configuration will be IMHO easier. PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? After 1.2.0, If I figure out how to do that cross-server. I'll make that for jk2 first, I hope :). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
Cool! Bojan Quoting Mladen Turk [EMAIL PROTECTED]: -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 12:00 AM To: Tomcat Dev List Subject: RE: mod_jk, mod_jk2 URI spaces This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. Yes something like that. This will allow to serve the compiled applications and still deliver the static context from those locations, overlaying Apache URI space (if set) over already resolved TC uri space. Well, at least the configuration will be IMHO easier. PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? After 1.2.0, If I figure out how to do that cross-server. I'll make that for jk2 first, I hope :). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
