You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2002/07/31 15:37:30 UTC
mod_jk, mod_jk2 URI spaces
Hi,
Just been working for a week on a real-life TC-mod_jk situation, and
found some interesting limitations (well, point of views to the
concept).
What are we doing right now is 'favoring' TC over Apache URI resolving,
meaning that if we set something like /*.html, then all the .html
context will be server by the TC.
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?
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: mod_jk, mod_jk2 URI spaces
Posted by Bojan Smojver <bo...@rexursive.com>.
Cool!
Bojan
Quoting Mladen Turk <mt...@mappingsoft.com>:
> > -----Original Message-----
> > From: Bojan Smojver [mailto:bojan@rexursive.com]
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: mod_jk, mod_jk2 URI spaces
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: Bojan Smojver [mailto:bojan@rexursive.com]
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: mod_jk, mod_jk2 URI spaces
Posted by Bojan Smojver <bo...@rexursive.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: mod_jk, mod_jk2 URI spaces
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: mod_jk, mod_jk2 URI spaces
Posted by Mladen Turk <mt...@mappingsoft.com>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>