You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@eng.sun.com on 2000/01/25 22:08:32 UTC
Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
I hope we'll have very soon a clear architecture documentation with all
the details !
ContextManager != virtual host.
How it should work ( in the current architecture - read Apache docs also,
since it's very similar) :
- Context represents a WebApplication. It should contain all the Context
information, plus web.xml and server.xml, and methods to access it, but
nothing else. ( i.e. no request processing methods ) ( for apache users:
dir_rec, I don't remember the ISAPI or NSAPI equiv )
- Request is also a "passive" object, it contains all request informations
and any "hints" ( request_rec )
- ContextManager is the entry point into tomcat. It contain all the logic
for request processing - i.e. calling a set of interceptors (
http_request ). It doesn't care about virtual hosts or anything else, just
about invoking the interceptors. ( various stages in apache modules ).
- RequestInterceptors are small and specialized processing units that
operate on Request. One RequestInterceptor might set the virtual host,
other might find the context based on mappings, context path and virtual
host. Take a look at Apache/NSAPI/ISAPI modules/filters/extensions - same
theory.
Adding virtual host support should mean adding a new RequestInterceptor.
( for standalone case - Apache doesn't need such a thing because it handle
that and will send the resolved context). That also mean that we'll
support virtual hosts, authentication, aliasing, etc as soon as we improve
the apache integration.
I think this model has some clear advantages:
- it is very flexible ( proved in : Apache, NSAPI, ISAPI )
- it will allow _great_ optimizations ( both speed and memory ). A small
embeded web server doesn't need virtual hosts - so we don't need to
install the interceptors.
- it allow paralel development ( "stable" interceptors and "experimental"
interceptors)
- we can reach it with incremental changes
I also like this model because it may allow ( in Apache 2.0 with embeded
java) writing of Apache modules in Java ( like mod_perl ), and using of
sophisticated Apache moduels from tomcat.
I also think that it has the minimum "overhead" of concepts you need to be
aware in order to develop Tomcat code. It reduce the core to:
- ContextManager - request processing logic
- Context - context informations repository
- Request - request informations ( and adapter )
- Response - response informations ( and adapter )
All serving a clear ( and single ) function.
The current code base is not respecting those rules, but it's not hard to
get there, and it can be done gradually ( assuming people will add new
functionality in modules/interceptors and clean up the main classes as we
go)
What do you think?
Costin
> I put TomcatServer in to allow all context managers to be started and
> stopped together through the admin interface. It pretty much corresponds to
> the <server> part of server.xml.
>
> I think you need multiple context managers for multiple virtual hosts (IP
> based) on one server. In fact, I guess a contextManager is roughly
> equivalent to a virtual host since it defines a namespace for contexts
> (mapped into that namespace via their path attribute). Makes me wonder about
> how name-based virtual hosting would work with Tomcat? For that you almost
> need the connectors defined outside the context managers and something to
> route incoming connections to context managers. In that scenario, the
> hostname and port would make sense as attributes of the context manager to
> be matched against the information from the connection. What do you think?
Re: [Catalina] Context sandbox
Posted by Assaf Arkin <ar...@exoffice.com>.
> Yes, I think that this would work... the most important thing is the
> read/write access outside the users home directory. In other words, at the
> very least, a context should not have access to read/write outside its own
> root directory. Of course there are other possible problems should a user
> decide to initiate a DOS attack (sucking up all the memory, infinite loops,
> etc.) but that is a much larger problem that could also be caused by a JSP
> page. and in my opionion, not as severe as the r/w problem.
Assuming you are using JDK 1.2, check out the java.policy file under
/jdk/lib/security.
arkin
>
> - Brill Pappin
> www.jmonkey.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: [Catalina] Context sandbox
Posted by Brill Pappin <br...@jmonkey.com>.
----- Original Message -----
From: Assaf Arkin <ar...@exoffice.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, January 27, 2000 8:09 PM
Subject: Re: [Catalina] Context sandbox
>
> Different approach:
>
> 1. Servlets can only be deployed if the user has write access to the
> document base. So we can use the existing FS permissions to decide which
> user can put what Servlets where.
In this case the user does have access to the document base... i.e. I create
a public_html directory inside my home directory... Currently for this to
work without using Apache (using the internal HTTP server) a context has to
be created... and that means I can add a WEB-INF directory with all the bits
and peices.
I actually like the fact that I can give my users that kind of control, but
as a responsible admin, I sould make sure that one of those users can't kill
the server, or another users environment (aside from a ream of other
mischeif that a user *might* get up to).
> 2. All Servlets should run without any Java permission (i.e. empty
> policy) equivalent to the Applet sandbox.
>
> 3. Servlets that require specific permissions can be given these
> permissions either through the Java policy file, or some authentication
> mechanism.
>
> Will that work for you?
Yes, I think that this would work... the most important thing is the
read/write access outside the users home directory. In other words, at the
very least, a context should not have access to read/write outside its own
root directory. Of course there are other possible problems should a user
decide to initiate a DOS attack (sucking up all the memory, infinite loops,
etc.) but that is a much larger problem that could also be caused by a JSP
page. and in my opionion, not as severe as the r/w problem.
- Brill Pappin
www.jmonkey.com
Re: [Catalina] Context sandbox
Posted by Assaf Arkin <ar...@exoffice.com>.
Different approach:
1. Servlets can only be deployed if the user has write access to the
document base. So we can use the existing FS permissions to decide which
user can put what Servlets where.
2. All Servlets should run without any Java permission (i.e. empty
policy) equivalent to the Applet sandbox.
3. Servlets that require specific permissions can be given these
permissions either through the Java policy file, or some authentication
mechanism.
Will that work for you?
arkin
Brill Pappin wrote:
>
> Are there any plans to put the server context into a sandbox?
>
> here's the situation that made me think of it.
>
> On my server, I've given each user their own context as a way of emulating
> the <server>/~user paradigm of Apache... I've found this have many other
> benefits besides the emulation... however it leaves the server open to
> attack from user accounts, as all the contexts run under the same security
> privileges as the main context... a malicious (or just plain badly written)
> servlet could cause DOS problems or worse. i.e. If I run tomcat under a
> super user, any users on the system will have access to whatever the SU has
> access to.
> God forbid I run the server as root!
>
> Anyway, here is one of the context entries in my server.xml so you get an
> idea of what I'm talking about:
>
> <Context path="/~bpappin" docBase="/export/home/bpappin/public_html"
> defaultSessionTimeOut="30" isWARExpanded="true"
> isWARValidated="false" isInvokerEnabled="true"
> isWorkDirPersistent="false"/>
>
> For those of you who don't know how this works, it basically means that I
> (as
> a user) have complete control over the classes I want to deploy, and can add
> and remove them at will. This is itself is a great thing that most servlet
> engines don't have... but a way to secure the rest of the system is needed.
>
> It may be that the best way to deal with this is via. FS permissions, but I
> think we should explore some more integrated and server controlled
> methods...
> this will help prevent people who are not security conscious from making to
> many mistakes.
>
> - Brill Pappin
> www.jmonkey.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: [Catalina] Context sandbox
Posted by Brill Pappin <br...@jmonkey.com>.
----- Original Message -----
From: <co...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, January 27, 2000 12:10 PM
Subject: Re: [Catalina] Context sandbox
> > Are there any plans to put the server context into a sandbox?
>
> Yes, but that requires JDK1.2 ( J2EE is doing that already ).
>
> I don't think we can have it in 3.1, but it should be on the todo list
> and it will be great if someone can contribute it ( sooner the better :-).
<chuckle> I keep forgetting that its 1.1 complient! :) I only work in 1.2
now... I'll have to watch that I don't do any work thats 1.2 dependant...
> > God forbid I run the server as root!
>
> Agree, another piece we need is a "chuid" - you need to start as root in
> order to use port 80.
Yes... I find that I usually have to run the system under a very powerful
user anyway...
> > It may be that the best way to deal with this is via. FS permissions,
but I
> > think we should explore some more integrated and server controlled
> > methods...
> > this will help prevent people who are not security conscious from making
to
> > many mistakes.
>
> Yes, and also it's important to prevent one context from seeing data in
> another context ( that means we need to add security manager to
> HttpRequest.getRealRequest())
Hmm... it might be good to have contexts work in a hierarcical way, so that
nested contexts could inherit from their supers. i.e. The root context might
have another context below it, that was for a particular application... By
nested I'm talking about directory structure.
Context name=/ path=/root
Context name=/app path=/root/app
in the example above, the root context should be able to r/w into the app
context, but the app context should not be able to read the root. This
concept could be expanded at a later time for things like session and
application scope inheritance.
Re: [Catalina] Context sandbox
Posted by co...@eng.sun.com.
> Are there any plans to put the server context into a sandbox?
Yes, but that requires JDK1.2 ( J2EE is doing that already ).
I don't think we can have it in 3.1, but it should be on the todo list
and it will be great if someone can contribute it ( sooner the better :-).
> God forbid I run the server as root!
Agree, another piece we need is a "chuid" - you need to start as root in
order to use port 80.
> It may be that the best way to deal with this is via. FS permissions, but I
> think we should explore some more integrated and server controlled
> methods...
> this will help prevent people who are not security conscious from making to
> many mistakes.
Yes, and also it's important to prevent one context from seeing data in
another context ( that means we need to add security manager to
HttpRequest.getRealRequest())
Costin
[Catalina] Context sandbox
Posted by Brill Pappin <br...@jmonkey.com>.
Are there any plans to put the server context into a sandbox?
here's the situation that made me think of it.
On my server, I've given each user their own context as a way of emulating
the <server>/~user paradigm of Apache... I've found this have many other
benefits besides the emulation... however it leaves the server open to
attack from user accounts, as all the contexts run under the same security
privileges as the main context... a malicious (or just plain badly written)
servlet could cause DOS problems or worse. i.e. If I run tomcat under a
super user, any users on the system will have access to whatever the SU has
access to.
God forbid I run the server as root!
Anyway, here is one of the context entries in my server.xml so you get an
idea of what I'm talking about:
<Context path="/~bpappin" docBase="/export/home/bpappin/public_html"
defaultSessionTimeOut="30" isWARExpanded="true"
isWARValidated="false" isInvokerEnabled="true"
isWorkDirPersistent="false"/>
For those of you who don't know how this works, it basically means that I
(as
a user) have complete control over the classes I want to deploy, and can add
and remove them at will. This is itself is a great thing that most servlet
engines don't have... but a way to secure the rest of the system is needed.
It may be that the best way to deal with this is via. FS permissions, but I
think we should explore some more integrated and server controlled
methods...
this will help prevent people who are not security conscious from making to
many mistakes.
- Brill Pappin
www.jmonkey.com
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by Assaf Arkin <ar...@exoffice.com>.
costin@eng.sun.com wrote:
> That's my opinion too !
> All configuration needs to be in the server/context, not in interceptors,
> and interceptors need to just use it. It' different from Apache, but I
> think it's much better.
Easier to configure for the common case.
> ( or tomcat.xml ). Now it's very easy.
Figure out which one is about the contexts their configurations, hosts,
security realms, etc the application deployment properties, and which
one is about the interceptors, adaptors, SSL certificate, the
environment configuration properties. Should make a clear distinction,
so the sysadmin will manage one, the application deployer will manage
the other.
>
> Another advantage is configuring contexts/context group is that you can
> switch Interceptors without any effort - the interceptor will just use the
> context configuration, you shouldn't care for the internals of the
> interceptor.
+1
> ( it is possible to use "context parameters" for specific tuning, but we
> should add new properties for anything that is generic, like virtual host
> for a context, or context group. This is another reason why contexts
> shouldn't be used for processing, they already are too complex )
+1
arkin
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by co...@eng.sun.com.
On Wed, 26 Jan 2000, Assaf Arkin wrote:
> But I would still like to see someway to map virtual hosts into
> collections of contexts, paths, etc and as part of the server
> configuration not the interceptor configuration.
That's my opinion too !
All configuration needs to be in the server/context, not in interceptors,
and interceptors need to just use it. It' different from Apache, but I
think it's much better.
It is ok to add a CollectionOfContexts to the object model, but it
should be just that - a collection of contexts, with no active role in
request processing.
What's critical is the mapping alghoritm, and (IMHO) it's better to keep
it in one place instead of spreading it, and you can have a better
alghoritm too ( let's say by using a tree instead of several hashtables)
> IMHO Tomcat deployers would like to not bother with interceptors but
> bother more with contexts or super-context (i.e. a virtual host, or a
> path mapping into multiple JARs).
Yes, but it's a difference between what's good for deployers ( intuitive
configuration and model ) and what's good for tomcat ( fast alghoritms,
etc). Normal interceptors should have no configuration.
> So server.xml should accomodate the host/path/context definitions, allow
> interceptors to be specified but not require them. Some other
> configuration file (or other part of server.xml) should specify the
> general set of interceptors. These interceptors will then figure out how
> they should behave based on the configuration.
Yes, I was thinking to add a "vhost" attribute to <context> in server.xml
( or tomcat.xml ). Now it's very easy.
Another advantage is configuring contexts/context group is that you can
switch Interceptors without any effort - the interceptor will just use the
context configuration, you shouldn't care for the internals of the
interceptor.
( it is possible to use "context parameters" for specific tuning, but we
should add new properties for anything that is generic, like virtual host
for a context, or context group. This is another reason why contexts
shouldn't be used for processing, they already are too complex )
Costin
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by Assaf Arkin <ar...@exoffice.com>.
I like this design and it seems to scale very well when new complexity
is added in.
But I would still like to see someway to map virtual hosts into
collections of contexts, paths, etc and as part of the server
configuration not the interceptor configuration.
IMHO Tomcat deployers would like to not bother with interceptors but
bother more with contexts or super-context (i.e. a virtual host, or a
path mapping into multiple JARs).
Generally you would want to say which interceptors to use at one point
(or use a default configuration), and only deal with mapping virtual
hosts, paths etc into contexts and super-contexts. You can always
override the interceptor list of a given context if it does something
special.
So server.xml should accomodate the host/path/context definitions, allow
interceptors to be specified but not require them. Some other
configuration file (or other part of server.xml) should specify the
general set of interceptors. These interceptors will then figure out how
they should behave based on the configuration.
For example, you could associate an authentication interceptor with a
given context or virtual host and specify its attributes. But you can
also associate the authentication interceptor with all contexts and let
it figure out how to map hosts into the information it needs. A default
implementation would map www.mycom.com into LDAP query for
dc=mycom,dc=com.
arkin
costin@eng.sun.com wrote:
>
> I hope we'll have very soon a clear architecture documentation with all
> the details !
>
> ContextManager != virtual host.
>
> How it should work ( in the current architecture - read Apache docs also,
> since it's very similar) :
>
> - Context represents a WebApplication. It should contain all the Context
> information, plus web.xml and server.xml, and methods to access it, but
> nothing else. ( i.e. no request processing methods ) ( for apache users:
> dir_rec, I don't remember the ISAPI or NSAPI equiv )
>
> - Request is also a "passive" object, it contains all request informations
> and any "hints" ( request_rec )
>
> - ContextManager is the entry point into tomcat. It contain all the logic
> for request processing - i.e. calling a set of interceptors (
> http_request ). It doesn't care about virtual hosts or anything else, just
> about invoking the interceptors. ( various stages in apache modules ).
>
> - RequestInterceptors are small and specialized processing units that
> operate on Request. One RequestInterceptor might set the virtual host,
> other might find the context based on mappings, context path and virtual
> host. Take a look at Apache/NSAPI/ISAPI modules/filters/extensions - same
> theory.
>
> Adding virtual host support should mean adding a new RequestInterceptor.
> ( for standalone case - Apache doesn't need such a thing because it handle
> that and will send the resolved context). That also mean that we'll
> support virtual hosts, authentication, aliasing, etc as soon as we improve
> the apache integration.
>
> I think this model has some clear advantages:
> - it is very flexible ( proved in : Apache, NSAPI, ISAPI )
> - it will allow _great_ optimizations ( both speed and memory ). A small
> embeded web server doesn't need virtual hosts - so we don't need to
> install the interceptors.
> - it allow paralel development ( "stable" interceptors and "experimental"
> interceptors)
> - we can reach it with incremental changes
>
> I also like this model because it may allow ( in Apache 2.0 with embeded
> java) writing of Apache modules in Java ( like mod_perl ), and using of
> sophisticated Apache moduels from tomcat.
>
> I also think that it has the minimum "overhead" of concepts you need to be
> aware in order to develop Tomcat code. It reduce the core to:
> - ContextManager - request processing logic
> - Context - context informations repository
> - Request - request informations ( and adapter )
> - Response - response informations ( and adapter )
>
> All serving a clear ( and single ) function.
>
> The current code base is not respecting those rules, but it's not hard to
> get there, and it can be done gradually ( assuming people will add new
> functionality in modules/interceptors and clean up the main classes as we
> go)
>
> What do you think?
>
> Costin
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by Assaf Arkin <ar...@exoffice.com>.
I will also be looking forward for some way to get an object associated
with preService and postService that belongs to the Interceptor (not
viewable to the Servlet).
One possibility, is for preService to return a value and for postService
to pass it back as argument. Simple state management. It shouldn't be
mode sophisticated than that. For anything more complex (or easier to
write) use Valves.
arkin
> For ServiceInterceptors in the Tomcat 3.0 architecture (or Interceptors under
> Catalina) the simplest way to save per-request state would be to use request
> attributes, since the request is passed as an argument to both methods. One
> possible down side is that this exposes your objects to application level scrutiny,
> since servlets can examine these attributes as well. (Under Catalina, it would be
> possible to define an internal-to-the-server request attributes mechanism since
> Request is passed -- under Tomcat 3.x this isn't possible since HttpServletRequest
> is passed).
>
> Under the Catalina Valve design pattern, you can also use local variables in the
> invoke() method to maintain per-request state, since there is a stack per thread.
> This is one of the reasons I have tended to like Valves better.
>
> >
> > Any guidance appreciated.
> > Thanks.
> > Shawn
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Shawn McMurdo wrote:
> Costin,
> Thank you for your efforts to clean up and simplify the core architecture!
> I like the proposed Catalina Interceptor model a lot.
> It seems very flexible and powerful.
>
> I do have a simple question regarding Interceptors which also applies
> to the current 3.0 Interceptors.
> How can I share data between the preInvoke (preService) and
> postInvoke (postService) methods for the same request?
> A single instance of the ServiceInterceptor is used for a Context
> which could be handling many concurrent requests for both the same
> and different Servlets.
For ServiceInterceptors in the Tomcat 3.0 architecture (or Interceptors under
Catalina) the simplest way to save per-request state would be to use request
attributes, since the request is passed as an argument to both methods. One
possible down side is that this exposes your objects to application level scrutiny,
since servlets can examine these attributes as well. (Under Catalina, it would be
possible to define an internal-to-the-server request attributes mechanism since
Request is passed -- under Tomcat 3.x this isn't possible since HttpServletRequest
is passed).
Under the Catalina Valve design pattern, you can also use local variables in the
invoke() method to maintain per-request state, since there is a stack per thread.
This is one of the reasons I have tended to like Valves better.
>
> Any guidance appreciated.
> Thanks.
> Shawn
>
Craig McClanahan
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by co...@eng.sun.com.
On Thu, 27 Jan 2000, Shawn McMurdo wrote:
> I do have a simple question regarding Interceptors which also applies
> to the current 3.0 Interceptors.
> How can I share data between the preInvoke (preService) and
> postInvoke (postService) methods for the same request?
Using the Request object ? ( you can set attributes for example).
It's not a perfect solution ( because attributes are visible to the
servlet ). We can add a "private" attributes in Request to be used only by
interceptors, or if the "data" is of general interest we can add get/set
method in request.
( please note that Catalina and the "current" interceptors are a bit
different, in Catalina most of the request processing is inside Containers
while in the "current" all processing is in interceptors - like in
Apache. )
Costin
Re: Interceptors in tomcat ( was: [PATCH] Remove HTTPServer)
Posted by Shawn McMurdo <sh...@lutris.com>.
Costin,
Thank you for your efforts to clean up and simplify the core architecture!
I like the proposed Catalina Interceptor model a lot.
It seems very flexible and powerful.
I do have a simple question regarding Interceptors which also applies
to the current 3.0 Interceptors.
How can I share data between the preInvoke (preService) and
postInvoke (postService) methods for the same request?
A single instance of the ServiceInterceptor is used for a Context
which could be handling many concurrent requests for both the same
and different Servlets.
Any guidance appreciated.
Thanks.
Shawn
costin@eng.sun.com wrote:
> I hope we'll have very soon a clear architecture documentation with all
> the details !
>
> ContextManager != virtual host.
>
> How it should work ( in the current architecture - read Apache docs also,
> since it's very similar) :
>
> - Context represents a WebApplication. It should contain all the Context
> information, plus web.xml and server.xml, and methods to access it, but
> nothing else. ( i.e. no request processing methods ) ( for apache users:
> dir_rec, I don't remember the ISAPI or NSAPI equiv )
>
> - Request is also a "passive" object, it contains all request informations
> and any "hints" ( request_rec )
>
> - ContextManager is the entry point into tomcat. It contain all the logic
> for request processing - i.e. calling a set of interceptors (
> http_request ). It doesn't care about virtual hosts or anything else, just
> about invoking the interceptors. ( various stages in apache modules ).
>
> - RequestInterceptors are small and specialized processing units that
> operate on Request. One RequestInterceptor might set the virtual host,
> other might find the context based on mappings, context path and virtual
> host. Take a look at Apache/NSAPI/ISAPI modules/filters/extensions - same
> theory.
>
> Adding virtual host support should mean adding a new RequestInterceptor.
> ( for standalone case - Apache doesn't need such a thing because it handle
> that and will send the resolved context). That also mean that we'll
> support virtual hosts, authentication, aliasing, etc as soon as we improve
> the apache integration.
>
> I think this model has some clear advantages:
> - it is very flexible ( proved in : Apache, NSAPI, ISAPI )
> - it will allow _great_ optimizations ( both speed and memory ). A small
> embeded web server doesn't need virtual hosts - so we don't need to
> install the interceptors.
> - it allow paralel development ( "stable" interceptors and "experimental"
> interceptors)
> - we can reach it with incremental changes
>
> I also like this model because it may allow ( in Apache 2.0 with embeded
> java) writing of Apache modules in Java ( like mod_perl ), and using of
> sophisticated Apache moduels from tomcat.
>
> I also think that it has the minimum "overhead" of concepts you need to be
> aware in order to develop Tomcat code. It reduce the core to:
> - ContextManager - request processing logic
> - Context - context informations repository
> - Request - request informations ( and adapter )
> - Response - response informations ( and adapter )
>
> All serving a clear ( and single ) function.
>
> The current code base is not respecting those rules, but it's not hard to
> get there, and it can be done gradually ( assuming people will add new
> functionality in modules/interceptors and clean up the main classes as we
> go)
>
> What do you think?
>
> Costin
>
>
>
> > I put TomcatServer in to allow all context managers to be started and
> > stopped together through the admin interface. It pretty much corresponds to
> > the <server> part of server.xml.
> >
> > I think you need multiple context managers for multiple virtual hosts (IP
> > based) on one server. In fact, I guess a contextManager is roughly
> > equivalent to a virtual host since it defines a namespace for contexts
> > (mapped into that namespace via their path attribute). Makes me wonder about
> > how name-based virtual hosting would work with Tomcat? For that you almost
> > need the connectors defined outside the context managers and something to
> > route incoming connections to context managers. In that scenario, the
> > hostname and port would make sense as attributes of the context manager to
> > be matched against the information from the connection. What do you think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Shawn McMurdo mailto:shawn@lutris.com
Lutris Technologies http://www.lutris.com
Enhydra.Org http://www.enhydra.org