Connector -- Context Manager relation

[Michal Mosiewicz <mi...@interdata.com.pl>]

Just wanted to ask - why connector is attached to context manager, not
to server? It is potential source of problems in case someone wants to
make his tomcat to serve for several vhosts.

Normally he would probably use just one address:port to attach it to
apache. However what happens if he configure two contexts with exactly
the same connector? Supposedly he will get unable-to-bind exception,
right? 

IMHO, connectors should belong to <server>... The relation between the
connector and the context manager is based on the vhost, which is
calculated during request processing phase, so it's not wise to assume
this relation earlier.

-- Mike

Re: Connector -- Context Manager relation

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

Michal Mosiewicz wrote:

> costin@eng.sun.com wrote:
> > [...]
> > Tomcat works right now without having an explicit VHost object,
> > and I don't see any reason to add it.
>
> Hmmm... I asked this question becouse I'm trying to move my current
> development to JSDK 2.2 to get ready for production. I've got about 20
> or more projects being developed, and to be able to work on all of them
> I would have to start 20 copies of tomcat, becouse _right now_ I'm not
> able to configure each virtual host separately.  <grin>

Ops, that's a different story...  ContextGroup ( or even it's special form
-
VirtualHost ) is fine for configuration purpose, and it would be great to
have such feature.

I just don't want it too deeply involved in the initial request processing

phase - I want to have all the critical code in Adapter, ContextManager,
RequestMapper and some Interceptors.

Costin

Re: Connector -- Context Manager relation

[Michal Mosiewicz <mi...@interdata.com.pl>]

costin@eng.sun.com wrote:
> [...]
> Tomcat works right now without having an explicit VHost object,
> and I don't see any reason to add it.

Hmmm... I asked this question becouse I'm trying to move my current
development to JSDK 2.2 to get ready for production. I've got about 20
or more projects being developed, and to be able to work on all of them
I would have to start 20 copies of tomcat, becouse _right now_ I'm not
able to configure each virtual host separately.  <grin>

-- Mike

Re: Connector -- Context Manager relation

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

> Yes - apache knows the exact context, but how are you going to identify
> this context if not using
> 'vhost:/path'? I'm rather tending to say that current zone mangling is
> not a perfect solution

Apache knows both the virtual host ( it's part of request_rec, isn't it? )
and can find the context name ( and determine all other components
of the path).
I just don't want to do the same parsing twice.

Tomcat works right now without having an explicit VHost object,
and I don't see any reason to add it.
The logic is there, inside a method, it's just the class structure I'm
talking about.

ContextGroup is better than VHost for most purposes - VHost is
just a particular case.

And VHost shouldn't be used for parsing ( or in the critical path ).
Parsing is expensive, and it is easier to optimize it ( and debug it) if
you have the code in one class ( RequestParserInterceptor? ).


> apache, the parameter have to be passed -- maybe mangled -- but it just
> have to be passed unless you're going to factor out to apache things
> like sessions. You cannot fully isolate java engine from the knowledge
> about how to find a context, no matter if in distributed or compact
> environment, you have to keep context manager being able to dispatch
> resources inside specific vhost space, right?

Yes, tomcat needs to know how to parse a request line anyway
( for the embeded server, and to support RequestDispatcher ).

I just want to keep all critical code grouped in fewer classes, and to
not _require_ a specific way of doing the parsing ( i.e. being able
to replace the whole RequestParser with a better one without changing
to much).

Something like:
interface RequestParser {
    Context getContext( Request req );

  String getVirtualHostName( Request req );
  ( or even VirtualHost getVHost( req ) !!!  or ContextGroup[]  getContextGroups(req ) )
}

Instead of
ContextManager {
   lookupVHost( req)
VHost {
    lookupContext( req )
}

Costin

Re: Connector -- Context Manager relation

[Michal Mosiewicz <mi...@interdata.com.pl>]

costin@eng.sun.com wrote:
> [....]
> 2. Adapters.
>      If we use apache instead of the embeded web server, the adapter will likely know
> the exact context ( i.e. apache can easily give us this information). That means the
> VHost class will be used in only one case - the embeded web server. 

Yes - apache knows the exact context, but how are you going to identify
this context if not using
'vhost:/path'? I'm rather tending to say that current zone mangling is
not a perfect solution.

Also, don't forget that the engine is not allowed to work in total
abstraction of vhost parameter. Even if the context is choosen in the
apache, the parameter have to be passed -- maybe mangled -- but it just
have to be passed unless you're going to factor out to apache things
like sessions. You cannot fully isolate java engine from the knowledge
about how to find a context, no matter if in distributed or compact
environment, you have to keep context manager being able to dispatch
resources inside specific vhost space, right? So, it has to be able to
find other contexts belonging to that vhost, which lead us to the
conclusion that more or less it has to have some knowledge about vhost,
even if we don't call it a vhost (or VHost.java) and we name it a
groupping entity.

-- Mike

Re: Connector -- Context Manager relation

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

"Craig R. McClanahan" wrote:

> Michal Mosiewicz wrote:
>
> > costin@eng.sun.com wrote:
> > > [...]
> > > About "Host" - what's the meaning of "host" in terms of servlet api, and why
> > > is it needed? Right now we have the server singleton ( == a tomcat engine instance,
> > > ContextManger ), and we have Contexts. It is up to ContextManager ( with help
> > > from Adapter and maybe Interceptors ) to find the right context and invoke service.
> > > I don't see a need to add a "virtual host" concept into this picture
> >
> > As you remember I never liked vhost concept implementations. But still -
> > if we have the same engine shared for several web servers (we may call
> > them vhosts), the engine should be able to configure contexts
> > differently depending on the vhost. I'm not suggesting any specific
> > implementation, I'm not saying that a class is needed, but I'm just
> > missing something from this picture.
> >
>
> Another example where a virtual host component comes in handy is when you want to
> provide per-virtual-host level access logs (presuming you are running stand alone and
> not attached to Apache).  This would be really easy to implement as a virtual host level
> Interceptor, where the postInvoke() method can look at the response that was created to
> prepare its log entry.

There are few arguments I have against a VHost.java class.

1.  "application" == Context
     VHost is one way to group applications, but it is not the only one and represent only
one particular case ( like an ISP providing hosting, and each customer gets a virtual
costin.foo.com host ). The other case is: customer gets a subspace of a vhost -
www.foo.com/costin, and he deploys several apps in this subspace.
Or an intranet site, each department has a number of apps under a dir (
www.foo.com/dept/app ).

If we implement "application groups", we should go for the generic case - groups based
on the host part is just a particular case ( we can have a <vhost> config tag, but the API
should be the generic one ).

2. Adapters.
     If we use apache instead of the embeded web server, the adapter will likely know
the exact context ( i.e. apache can easily give us this information). That means the
VHost class will be used in only one case - the embeded web server. ( with a "smart"
adapter you'll never access the VHost object.) That also means that all logic you put
in VHost will not be used in some cases - or you'll force adapters that know the final
context ( because the web server has all the logic it needs ) to still pass the VHost and
repeat all parsing/hashtable lookups, etc.

3. Performance.
    Using Interceptors ( or other modular API ), we can optimize the critical path.
( if a site doesn't support vhosts, there is no need to know/parse the vhost name , except
if the servlet asks for it ). If a site has only one context - there is no need for almost
any
parsing at all.
Also, VHost means yet-another object used in the critical path - I would rather
have the critical path easier to read, it already span in many files.


We can have a VHost object if we want to - but after we factor out request parsing.


Costin

Re: Connector -- Context Manager relation

["Craig R. McClanahan" <cm...@mytownnet.com>]

Michal Mosiewicz wrote:

> costin@eng.sun.com wrote:
> > [...]
> > About "Host" - what's the meaning of "host" in terms of servlet api, and why
> > is it needed? Right now we have the server singleton ( == a tomcat engine instance,
> > ContextManger ), and we have Contexts. It is up to ContextManager ( with help
> > from Adapter and maybe Interceptors ) to find the right context and invoke service.
> > I don't see a need to add a "virtual host" concept into this picture
>
> As you remember I never liked vhost concept implementations. But still -
> if we have the same engine shared for several web servers (we may call
> them vhosts), the engine should be able to configure contexts
> differently depending on the vhost. I'm not suggesting any specific
> implementation, I'm not saying that a class is needed, but I'm just
> missing something from this picture.
>

Another example where a virtual host component comes in handy is when you want to
provide per-virtual-host level access logs (presuming you are running stand alone and
not attached to Apache).  This would be really easy to implement as a virtual host level
Interceptor, where the postInvoke() method can look at the response that was created to
prepare its log entry.

>
> -- Mike
>

Craig

Re: Connector -- Context Manager relation

[Michal Mosiewicz <mi...@interdata.com.pl>]

costin@eng.sun.com wrote:
> [...]
> About "Host" - what's the meaning of "host" in terms of servlet api, and why
> is it needed? Right now we have the server singleton ( == a tomcat engine instance,
> ContextManger ), and we have Contexts. It is up to ContextManager ( with help
> from Adapter and maybe Interceptors ) to find the right context and invoke service.
> I don't see a need to add a "virtual host" concept into this picture 

As you remember I never liked vhost concept implementations. But still -
if we have the same engine shared for several web servers (we may call
them vhosts), the engine should be able to configure contexts
differently depending on the vhost. I'm not suggesting any specific
implementation, I'm not saying that a class is needed, but I'm just
missing something from this picture.

-- Mike

Re: Connector -- Context Manager relation

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

> It wouldn't be needed for the servlet API, but would be useful if you wanted to give an
> ISP, for example, a place to inject Interceptors that processed all requests to a
> particular customer's virtual host -- and the ability to use separate interceptors for
> each separate customer.

Yes, but you may want more - i.e. to customize interceptors ( == security, etc) by
Context. For an intranet site, you have different applications with different needs -
and this is not only vhost based.

vhost=one way to group Contexts, but you can have more ( of course,
setting restrictions per vhost is easier than arbitrary Context groups )


> > ( this also avoids the discussion about "can a Context be shared across multiple
> > virtual hosts" :-)
> >
>
> We can skip the discussion as long as you enforce the spec prohibition against crossing
> boundaries :-).

Sure, one Interceptor can do that - and we can write code to prevent anyone ( Mike?) from
turning it off :-)

Costin

Re: Connector -- Context Manager relation

[Craig McClanahan <cm...@mytownnet.com>]

costin@eng.sun.com wrote:

> > One question would be if there should be something in between the Connector and
> > Host layers that filters all incoming requests.  An advantage of this approach is
> > that you could install Interceptor type logic at any or all of the levels (entire
> > servlet engine, host, context, or wrapper) depending on your needs.
>
> It is a very  good ideea - the Interceptor behavior is very similar with Apache
> modules, i.e. it pre-process the request_rec in various ways.
>
> That may make the code cleaner and easier to follow - we can have a Interceptors
> that parse the request line and extract vhost/context ( and fix the paths),
> etc.
>
> About "Host" - what's the meaning of "host" in terms of servlet api, and why
> is it needed?

It wouldn't be needed for the servlet API, but would be useful if you wanted to give an
ISP, for example, a place to inject Interceptors that processed all requests to a
particular customer's virtual host -- and the ability to use separate interceptors for
each separate customer.

> Right now we have the server singleton ( == a tomcat engine instance,
> ContextManger ), and we have Contexts. It is up to ContextManager ( with help
> from Adapter and maybe Interceptors ) to find the right context and invoke service.
> I don't see a need to add a "virtual host" concept into this picture ( as a class
> with this
> name,  the logic is already inside the ContextManager code ).
> ( this also avoids the discussion about "can a Context be shared across multiple
> virtual
> hosts" :-)
>

We can skip the discussion as long as you enforce the spec prohibition against crossing
boundaries :-).

>
> Costin
>

Craig

Re: Connector -- Context Manager relation

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

> One question would be if there should be something in between the Connector and
> Host layers that filters all incoming requests.  An advantage of this approach is
> that you could install Interceptor type logic at any or all of the levels (entire
> servlet engine, host, context, or wrapper) depending on your needs.

It is a very  good ideea - the Interceptor behavior is very similar with Apache
modules, i.e. it pre-process the request_rec in various ways.

That may make the code cleaner and easier to follow - we can have a Interceptors
that parse the request line and extract vhost/context ( and fix the paths),
etc.


About "Host" - what's the meaning of "host" in terms of servlet api, and why
is it needed? Right now we have the server singleton ( == a tomcat engine instance,
ContextManger ), and we have Contexts. It is up to ContextManager ( with help
from Adapter and maybe Interceptors ) to find the right context and invoke service.
I don't see a need to add a "virtual host" concept into this picture ( as a class
with this
name,  the logic is already inside the ContextManager code ).
( this also avoids the discussion about "can a Context be shared across multiple
virtual
hosts" :-)

Costin

Re: Connector -- Context Manager relation

[Craig McClanahan <cm...@mytownnet.com>]

costin@Eng.Sun.COM wrote:

> Michal Mosiewicz wrote:
>
> > costin@eng.sun.com wrote:
> > > [...]
> > > "server" means too many things, I prefer ContextManager ( implements
> > > Server ) :-)
> > >
> > > There is no relation between Connector/Adapter and vhost - ContextManager
> > > will
> > > extract the local address and host header
> >
> > Anyhow it is a little bit tricky, that host:port is a property of
> > ContextManager - it suggests it is used only for a single vhost.
>
> I know, historical reasons, it will change. ( it's sort of "default" host/port
> )
>
> Costin
>

In JSERV1_1DEV, we called the virtual host component "Host", which made a lot of
sense, so I'd recommend it here as well.  The following relationships would be
possible:

* A Connector can connect to multiple Hosts (for
  example, an AJP connection to a single Apache
  instance that has multiple virtual hosts defined).

* Many Connectors can connect to one Host to allow
  for multiple communications paths (although I'm not
  sure how often this is really needed).

* A Host can connect to many Contexts (one per web
  application installed for that virtual host).

One question would be if there should be something in between the Connector and
Host layers that filters all incoming requests.  An advantage of this approach is
that you could install Interceptor type logic at any or all of the levels (entire
servlet engine, host, context, or wrapper) depending on your needs.

Craig

Re: Connector -- Context Manager relation

[co...@Eng.Sun.COM]

Michal Mosiewicz wrote:

> costin@eng.sun.com wrote:
> > [...]
> > "server" means too many things, I prefer ContextManager ( implements
> > Server ) :-)
> >
> > There is no relation between Connector/Adapter and vhost - ContextManager
> > will
> > extract the local address and host header
>
> Anyhow it is a little bit tricky, that host:port is a property of
> ContextManager - it suggests it is used only for a single vhost.

I know, historical reasons, it will change. ( it's sort of "default" host/port
)

Costin

Re: Connector -- Context Manager relation

[Michal Mosiewicz <mi...@interdata.com.pl>]

costin@eng.sun.com wrote:
> [...]
> "server" means too many things, I prefer ContextManager ( implements
> Server ) :-)
> 
> There is no relation between Connector/Adapter and vhost - ContextManager
> will
> extract the local address and host header

Anyhow it is a little bit tricky, that host:port is a property of
ContextManager - it suggests it is used only for a single vhost.

-- Mike

Re: Connector -- Context Manager relation

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

> Just wanted to ask - why connector is attached to context manager, not
> to server? It is potential source of problems in case someone wants to
> make his tomcat to serve for several vhosts.

ContextManager is the main "entry point" in the servlet engine. Adapters
will construct a Request/Response and call ContextManager.service.
( for request processing ).

ContextManager should be  a "singleton".

One "Context" can have multiple "Connectors" ( i.e. you can access the
same
application via multiple protocols ).
One Connector can serve multiple Contexts.

Right now this is not implemented completely - and I don't see it as a
big
priority ( compared with other features, testing of the model, etc).


> Normally he would probably use just one address:port to attach it to
> apache. However what happens if he configure two contexts with exactly
> the same connector? Supposedly he will get unable-to-bind exception,
> right?

I don't think so - there is one ContextManager, it has several Connectors
( each
using different ports ).
You should be able to set a Context to use a certain connector ( the
current code
allows all connectors to see all Contexts ).



> IMHO, connectors should belong to <server>... The relation between the
> connector and the context manager is based on the vhost, which is
> calculated during request processing phase, so it's not wise to assume
> this relation earlier.

"server" means too many things, I prefer ContextManager ( implements
Server ) :-)

There is no relation between Connector/Adapter and vhost - ContextManager
will
extract the local address and host header and do the routing ( eventualy
using hints from
RequestAdapter if the adapter already knows the vhost or the context id )

Costin