The only way (that I'm aware) to do what you are suggesting is to implement a
PathCheck or a Service method in the Default object block. It has been a while since
I worked with these, but as I recall, every request is handed off to these functions
to determine if it should be handled by a particular plugin. The PathCheck lets you
check the incoming URI and see if it is one that you should handle and possibly add
some additional information into the request for later processing. Depending on how
(and where) the Service method is called, it can either process the request or respond
that it isn't interested. The NameTrans directive has to have a specific pattern to
match and can then direct the processing to different object blocks which is how the
current connectors work. It is more efficient because only the requests that match a
particular pattern are actually handed of to the additional processing. The Service
and PathCheck methods in the Default object block are more dynamic, but will be hit
for every request and so have the potential of slowing down the overall performance of
the web server.
Again, this is based on what I've read in the NSAPI programming guide and played with
on other plugins so I could be completely off base, but it matches behavior that I've
seen.
Mike Anderson
>>>> [EMAIL PROTECTED] 08/09/01 10:13AM >>>
>Colin Wilson-Salt at [EMAIL PROTECTED] wrote:
>
>> I've been looking at the existing web server integration stuff (both mod_jk
>> and mod_webapp), and it seems to me that there is one significant piece
>> missing - a NameTrans directive that takes its configuration from a separate
>> file.
>>
>> I know I'm talking iPlanet here - but that's where my experience is.
>
>Hmm... I don't know anything about NES as of now. I don't know how it works,
>how it's configured, how the API looks like... NOTHING :)
>
>I suppose that JK has something like that. They rely on external
>configuration files. Regarding mod_webapp, external configuration files are
>a big -1... No-No... Configuration should be effective, minimal and
>integrated with the web-server... If you see how Apache works, you have only
>ONE line of configuration per web-application, and all the rest is taken
>care automatically...
>
> Pier
