ApJServMount status

[Carlos Pita <ca...@aper.net>]

Hi!

    I'm very confused using the ApJServMount directive. I can't get URLs paths (in the first argument to ApJServMount) correctly mapped to the indicated context (in the second argument to ApJServMount).
    I'm asking here in the dev list because I need to know how well is the directive implemented, how could I help if there's some work pending and if I should use JServ for my web applications meanwhile.
    I have seen a number of questions without answer on this. I hope someone could give me a hint.

    Thank you in advance, Carlos.

RE: mod_jk?

[Carlos Pita <ca...@aper.net>]

----- Original Message ----- 
From: Gal Shachor <sh...@il.ibm.com>
To: <to...@jakarta.apache.org>
Sent: Wednesday, June 21, 2000 12:09 PM
Subject: Re: mod_jk?

> mod_jk is part of the native directory in the tomcat sourse tree and 
> since the night builds does not build the native code you will not have
> a prebuild version of it (yet) and you will need to build it yourself 
> from the source (there is a mod_jk howto that explaines how to build
> it).
> 
Where can I find that howto??

Thank you,

Carlos.

Re: mod_jk?

[Gal Shachor <sh...@il.ibm.com>]

mark@mjwilcox.com wrote:
>
> Is mod_jk part of the nightly builds or is it someplace else?
> 

mod_jk is part of the native directory in the tomcat sourse tree and 
since the night builds does not build the native code you will not have
a prebuild version of it (yet) and you will need to build it yourself 
from the source (there is a mod_jk howto that explaines how to build
it).

>
> Can someone summarize what's going to go into mod_jk?
> 

mod_jk?

[ma...@mjwilcox.com]

While I thought I had been doing a good job lurking, I missed these 
announcements.

Is mod_jk part of the nightly builds or is it someplace else?

Can someone summarize what's going to go into mod_jk?

thanks,

Mark

RE: ApJServMount status

[Carlos Pita <ca...@aper.net>]

----- Original Message -----
From: Costin Manolache <co...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Wednesday, June 21, 2000 11:00 AM
Subject: Re: ApJServMount status


> > >
> > Ok but....forget the examples. I mean that AJP12RequestAdapter shouldn't
> > read the context from the context item in the ajp protocol. Instead, it
> > could get it from the request URI (and maybe the host) like
PrefixMapper. In
>
> Apache ( or other web server) will parse the request and extract the
context
> path
> ( zone in mod_jserv, if you use the right mapping - i.e. no tricks ).
>
> We want to avoid duplicating the parsing ( which is expensive, part of the
> overhead).

Again:
I see two sources for the same thing in the actual code. One is the context
in the ajp protocol (well, I only guess there is one). The other is when
SimpleMapper1 calls PrefixMapper (remember my first walkthrough?).  Because
of:

>>  I'm not sure about the
> > relationship between all those Container types (getLongestPrefixMatch
> > returns an Object that is casted to Container) and a Context

I don't want to say they are exactly the same. But what I'm trying to say
is: if context comes from the web server don't parse it again, and if we
can't rely on it coming from the web server (or we can but we don't want to
get the same thing from 2 different sources) let's parse the requestURI.

I'm also aware of virtual servers and other facts that could justify that
choice, so I'm aware I could be very wrong with all this kind of uniformity.

Another thing: is a web server the right place to put enough context info in
order to let it parse the URL?

>
> Costin

Carlos

Re: ApJServMount status

[Costin Manolache <co...@eng.sun.com>]

>
> > Well, that's a different story - we wanted to minimize the changes in
> > mod_jserv ( too make it easy for JServ users ).
> >
> Ok but....forget the examples. I mean that AJP12RequestAdapter shouldn't
> read the context from the context item in the ajp protocol. Instead, it
> could get it from the request URI (and maybe the host) like PrefixMapper. In
> fact, I think it could use PrefixMapper but I'm not sure about the
> relationship between all those Container types (getLongestPrefixMatch
> returns an Object that is casted to Container) and a Context

Apache ( or other web server) will parse the request and extract the context
path
( zone in mod_jserv, if you use the right mapping - i.e. no tricks ).

We want to avoid duplicating the parsing ( which is expensive, part of the
overhead).

Costin

RE: ApJServMount status

[Carlos Pita <ca...@aper.net>]

----- Original Message -----
From: <co...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, June 20, 2000 4:26 PM
Subject: RE: ApJServMount status


> > That's ok but then: shouldn't AJP12RequestAdapter get the context from
the
> > requestURI instead from an useless (well, it's useful for protocol, host
&
> > port, but not for context) context parameter to ApJservMount? This way,
we
> > wouldn't write things like:
> > ApJservMount /examples /examples
> > Instead, we would write:
> > ApJservMount /examples
>
> Well, that's a different story - we wanted to minimize the changes in
> mod_jserv ( too make it easy for JServ users ).
>
Ok but....forget the examples. I mean that AJP12RequestAdapter shouldn't
read the context from the context item in the ajp protocol. Instead, it
could get it from the request URI (and maybe the host) like PrefixMapper. In
fact, I think it could use PrefixMapper but I'm not sure about the
relationship between all those Container types (getLongestPrefixMatch
returns an Object that is casted to Container) and a Context.

> Most of the development is done in mod_jk, which is right now far more
> powerfull ( supports Apache 2.0, NES, IIS, AOL ), and I hope ( soon
> ) we'll just make it the default.
>
I didn't know about mod_jk.

> I don't think we should try to fix ( or enhance ) mod_jserv, just move to
> mod_jk if you need a new feature.
>
Ok.

> Costin
Carlos.
>
>

RE: ApJServMount status

[co...@eng.sun.com]

> That's ok but then: shouldn't AJP12RequestAdapter get the context from the
> requestURI instead from an useless (well, it's useful for protocol, host &
> port, but not for context) context parameter to ApJservMount? This way, we
> wouldn't write things like:
> ApJservMount /examples /examples
> Instead, we would write:
> ApJservMount /examples

Well, that's a different story - we wanted to minimize the changes in
mod_jserv ( too make it easy for JServ users ).

Most of the development is done in mod_jk, which is right now far more
powerfull ( supports Apache 2.0, NES, IIS, AOL ), and I hope ( soon
) we'll just make it the default. 

I don't think we should try to fix ( or enhance ) mod_jserv, just move to
mod_jk if you need a new feature.

Costin

RE: ApJServMount status

[Carlos Pita <ca...@aper.net>]

----- Original Message -----
From: <co...@costin.dnt.ro>
To: <to...@jakarta.apache.org>
Sent: Monday, June 12, 2000 6:01 PM
Subject: RE: ApJServMount status


> Sorry for the late reply,
>
> I don't think this is the right fix - the 2.2 servlet spec requires that
> the context is determined from the URI prefix.
> I don't like that - but that's another story.

> Your proposal is a good way to do that, but we can't make it the default
> behavior.

That's ok but then: shouldn't AJP12RequestAdapter get the context from the
requestURI instead from an useless (well, it's useful for protocol, host &
port, but not for context) context parameter to ApJservMount? This way, we
wouldn't write things like:
ApJservMount /examples /examples
Instead, we would write:
ApJservMount /examples

> ( BTW, it would be nice if you edit a bit the request processing
> description and submit it into Faq-o-matic ! )
>
Ok. I'm working on it.

> Costin
>

RE: ApJServMount status

[co...@costin.dnt.ro]

Sorry for the late reply, 

I don't think this is the right fix - the 2.2 servlet spec requires that
the context is determined from the URI prefix. 
I don't like that - but that's another story.

If you want to implement a different "mount" system, where the context is
not the URI prefix - you can implement another Interceptor ( similar with
SimpleMapper) that will allow you to use the (non-standard) contexts.
Your proposal is a good way to do that, but we can't make it the default
behavior.

ApJservMount works in Servlet 2.2  only if the 2 paths are identical,
zones do map into contexts but "mounting" doesn't.

( BTW, it would be nice if you edit a bit the request processing
description and submit it into Faq-o-matic ! )

Costin


> gets on the task of finding that wrapper calling contextMap on each of the
> configurated RequestInterceptors. One of these interceptors will be
> SimpleMapper1 which would get the serverName and the requestURI from the
> request and put them into the variables host and path.  Then it will call
> getLongestPrefixMatch (which is a method of an asociated PrefixMapper)
> passing the args host and path and this polite method will return a
> container that will (finally!) bring the wrapper into life.

RE: ApJServMount status

[Carlos Pita <ca...@aper.net>]

Hi again!

    I was looking the CVS tree and I've some kind of beta answer to myself.
I'd like to commit the changes exposed here into (at least) my tomcat
sources but I think it would be better to get somebody else's points on this
first.

    "What's you solution?" i hear you asked. Here it's:

    (If some(posibly every)thing here is wrong please consider that I met
the CVS tree for the first time 2 hours before writing this)

The situation:
    First, the AJP12ConnectionHandler makes a nice AJP12RequestAdapter
(which is a specific case of RequestImpl). The request has useful fields
like context, serverName and requestURI, between others, which the rest of
the world sees from the HTTPServletRequest class interface. These fields are
filled by AJP12ConnectionHandler when processConnection'ing by the
invokation of readNextRequest method of the request adapter. Then the
connection handler wants to call the service method on the right servlet so,
not knowing how to do this by himself, it asks for help to the context
manager's service method, passing it the request as an argument. The context
manager then needs a servlet wrapper in order to invoke the method
handleRequest that will eventually call the appropiate service method. So it
gets on the task of finding that wrapper calling contextMap on each of the
configurated RequestInterceptors. One of these interceptors will be
SimpleMapper1 which would get the serverName and the requestURI from the
request and put them into the variables host and path.  Then it will call
getLongestPrefixMatch (which is a method of an asociated PrefixMapper)
passing the args host and path and this polite method will return a
container that will (finally!) bring the wrapper into life.

The problem:
    So the problem is: the context info is neither in the requestURI nor
(obviously) in the serverName. If the requestURI is prefixed with the right
context, everything is fine. But when the context is not prefixing the
requestURI, the wrapper obtained will belong to a wrong context (perhaps an
inexistent one).

The solution:
    To pass to getLongestPrefixMatch a string fixed by substituting the
mapped URI path with the right context to which it's mapped (this is
unnecesary when they're the same). This doesn't imply to change the
requestURI, only to temporarily generate and pass the suggested parameter to
getLongestPrefixMatch.

----- Original Message -----
From: Carlos Pita <ca...@aper.net>
To: <to...@jakarta.apache.org>
Sent: Monday, June 05, 2000 1:06 PM
Subject: ApJServMount status


Hi!

    I'm very confused using the ApJServMount directive. I can't get URLs
paths (in the first argument to ApJServMount) correctly mapped to the
indicated context (in the second argument to ApJServMount).
    I'm asking here in the dev list because I need to know how well is the
directive implemented, how could I help if there's some work pending and if
I should use JServ for my web applications meanwhile.
    I have seen a number of questions without answer on this. I hope someone
could give me a hint.

    Thank you in advance, Carlos.