tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session
Date Mon, 10 Jan 2000 18:48:56 GMT
> > In general, I think it's a bad ideea to have 2 places where web.xml properties are
> > i.e. once in Context and once in SessionManager.
> Why store the timeout value in the Context at all? It's only used by the Manager so
> it can go straight from web.xml to the Manager, during initialization as well as
> in-service updates (the day such management functions are added).

What about "distributable"? Is it a property of Manager?
It may be usefull to ClassLoader too - should class loader ask Manager for

I think that we will complicate a lot the system if we say "all web application
properties are set in Context except session-config/session-timeout which
is stored in Manager", and will impact the "configuration" architecture.

I would like to have Context as a repository for all web-application properties,
as it is used today and as it is my understanding of the HttpContext specification
( "The ServletContext defines the servlet view of a Web Application" ).
Do we have enough arguments against that ?

Storing in Manager also implies ( or requires ) the "one-to-one" relation.

> Okay, I guess it's a matter of preferense, but since each context can have
> different session management properties (such as timeouts, persistence, etc), having
> a unique Manager for each context (instead of sharing one between contexts) is a better
> approach IMHO.

It's a matter of preference - and of respecting other's preference too.
SessionManager can work both ways - you can create one instance per context
or one global instance. Why force me ( and I hope others ) design a SessionManager
in a certain way, when we have a solution that address both models ?

I see a reason to have multiple session managers - like DBSessionManager,
FileSessionManager, etc - but it should be possible to share a DBSessionManager
between various Contexts or configure the system however you want, not based on
an arbitrary design choice.

With session management preferences stored in Context and SessionManager
interface you can still delegate to Manager and implement your prefered solution,
without restricting others.


View raw message