Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

> > Okay, I see your point. So instead of having a the Context configuring the Manager,
> > you want the Manager to ask the Context, right? I can live with that, unless Craig
> > has some additional good reasons for keeping the Manager unaware of the Context
> > public methods.
> >
>
> Who creates new session objects?  If it's the session manager, then it needs to know the default
> timeout to properly initialize the value returned by getMaxInactiveInterval().  In addition, if you
> have an admin application adjusting the properties of a running web application, any changes to the
> default session timeout need to be forwarded to the session manager as the default for subsequent
> new sessions.

Or:
The admin application will change the context properties, including default maxInactiveInterval.
createSession() takes as parameter the Context - and SessionManager will ask for the current
value.
In addition to that, a smart SessionManager may use other informations in Context - like
attributes, or init parameters, or anything else - and that will not require changes in the
interface.

( example: a db session manager may set the db parameters using Context init parameters).

IMHO the second scenario can do whatever the first do. ( and reverse - but in that
case you'll take some informations from the Context, and maxInactiveInterval
locally- which is not so elegant, )


> > And that solution is asking the Context instead of the Context telling the Manager,
> > right? If that's the case, see my comment above. But I guess we have to agree to
> > disagree on the value of sharing a SessionManager instance between context; I still feel
> > it's much cleaner to use a unique instance for each context.
> >
>
> Sharing a session manager between contexts means that you have to delegate (to the session manager)
> the responsibilty to keep session info from one context leaking across to another (required by the
> servlet API spec).  I'd rather have an instance of a session manager per context, which can think of
> the entire universe of sessions related to that particular context.  (These instances can share
> back-end common functionality via singletons or whatever, but that's not the business of the
> Context).

Again - it is very easy to set one SessionManager per Context if you want this.
So if your SessionManager can't  keep session info local to a context - document
that and configure the server with one-one.

What if a future version of the servlet API will allow related contexts to share
session informations?  Yes, the current spec doesn't specify that, but spec
changes - that's the very reason Tomcat code is so complex today !!!

Please, don't say "that will never change". Even if it doesn't there is nothing wrong
in having a design that will permit people to even go beyond the standard spec
when they know what they're doing. ( yes, I work for Sun but I use my private
email - so I can say that :-)

For example, you have a big company with several web apps, and you don't want
people to log in for each section of the web site.

Costin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

costin@costin.dnt.ro wrote:
> 
> > > [...]
> > > What if a future version of the servlet API will allow related contexts to share
> > > session informations?  Yes, the current spec doesn't specify that, but spec
> > > changes - that's the very reason Tomcat code is so complex today !!!
> >
> > Possible future spec changes like this is not a motivation that's good enough
> > IMHO. If such a change is made, I assume all the related contexts would have
> > to share session attributes, such as time-out, as well as other attributes.
> > You would most likely end up with a new concept, like ContextGroup, to hold
> > all the shared attributes. And there would be a one-to-one between the ContextGroup
> > and the Manager.
> 
> 1. Tomcat is so complex because it had to implement spec changes. If you set
> arbitrary restrictions you'll be in the same situation, you can't change the
> architecture every day.

It's not an arbitrary restriction; today there's a one-to-one relationship between
sessions (attributes as well as data) and a Context. And as I described above,
even if the spec is changed to allow multiple Contexts to share sessions, they
will likely have to share the session attributes (time-out etc.) as well,
probably through a new Container subclass (ala Tomcat.next) called ContextGroup
or similar.

Besides, the spec doesn't change every day (more like once a year). And when it 
is changed it's discussed over a fairly long period so there's plenty of time to 
change the architecture if needed.

> 2. How do you deal with the "site with multiple related web apps,  need to
> share information - like only one login"?  ( just curiosity)

In the Tomcat.next model I just add an access control Interceptor on the 
ContextGroup level.

> 3. The issue is not if we should share or not Managers, but if we should
> have an architecture that have build-in restrictions that can be avoided.

I feel we should have an architecture that is natural for implementation of
the specification. Adding a Context parameter to all methods in SessionManager
when it's not needed for the type of session handling the spec defines today,
just to keep it open for one specific kind of possible spec change doesn't
make much sense to me. If we follow that approach we can dream up all kinds
of possible changes, and come up with an architecture that's so flexible it's
impossible to understand ;-)

> I don't care so much about shared sessions, my biggest problem was
> configuration ( i.e. timeout in context, Manager asks Context for it ).
> 
> And I don't see why you want it just one way, when it can be done
> in both ways easily - the default will be with one manager per
> context and you'll pass one extra parameter ( that you can
> ignore in your non-shareable manager).

Don't take this personally Costin. I'm only arguing for what I believe to be
the best architecture given what we know today. The reason Tomcat has one
SessionManager for all contexts is, most likely, because multi-context
configs is a pretty recent addition. With time pressures someone probably felt 
it would be faster to add a Context parameter here and there than to redesign 
session handling for the new requirements (I did exactly the same in LiteWebServer 
at first; now I have one session manager per context).

Passing on a parameter that's not used in the normal case, and only there
in case it's needed in a non-spec compliant implementation or for a possible
future change (that can be handled in a different way), simply is not a
clean design to me. I can se myself answering the question over and over
again: "Why is there a Context parameter everywhere that's never used?"

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

> > [...]
> > What if a future version of the servlet API will allow related contexts to share
> > session informations?  Yes, the current spec doesn't specify that, but spec
> > changes - that's the very reason Tomcat code is so complex today !!!
>
> Possible future spec changes like this is not a motivation that's good enough
> IMHO. If such a change is made, I assume all the related contexts would have
> to share session attributes, such as time-out, as well as other attributes.
> You would most likely end up with a new concept, like ContextGroup, to hold
> all the shared attributes. And there would be a one-to-one between the ContextGroup
> and the Manager.

1. Tomcat is so complex because it had to implement spec changes. If you set
arbitrary restrictions you'll be in the same situation, you can't change the
architecture every day.

2. How do you deal with the "site with multiple related web apps,  need to
share information - like only one login"?  ( just curiosity)

3. The issue is not if we should share or not Managers, but if we should
have an architecture that have build-in restrictions that can be avoided.

I don't care so much about shared sessions, my biggest problem was
configuration ( i.e. timeout in context, Manager asks Context for it ).

And I don't see why you want it just one way, when it can be done
in both ways easily - the default will be with one manager per
context and you'll pass one extra parameter ( that you can
ignore in your non-shareable manager).

Costin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

Hans Bergsten wrote:

> costin@costin.dnt.ro wrote:
> >
> > Speaking of "designing for unprobable situations" - I think "Manager shared between Contexts" is more usefull
> > and more probable than "Manager attached to something else than Context".
>
> Well, the way to share a Manager between multiple ("related") Contexts that I have
> suggested can be done with the Tomcat.next model is actually to associate the Manager
> with a Container, possibly named ContextGroup, higher up in the hierarchy. So that would
> be one case where the Manager is not associated with a Context.
>

Yep ... it's how you get what Costin was asking for (single session manager shared across contexts) if you want it,
but still have the manager tied to one and only one container.  I tried to be consistent about this and all the other
components you might want to attach at various levels in the hierarchy (such as a Realm to link to a shared database
of users and roles, or a shared Logger that lets you lump all the servlet.log() calls for an entire app, or an entire
Tomcat instance, together if you want).

>
> Hans

Craig

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

Hans Bergsten wrote:

> costin@costin.dnt.ro wrote:
> >
> > [...]
> > But now we have a design that _enforce_ it - which is great, but doesn't allow any
> > workaround ( well, except sharing between /a and /a/b ).
>
> It does, and more than the example you give. You can have apps with context roots
> /a, /b and /c, and introduce a ContextGroup component (a Container) that contains
> Context instances for /a, /b and /c. The ContextGroup has a Manager associated with
> it so sessions are shared between the three contexts.

Then why don't you said so ? :-)

Ok then, I still don't like the design but if I can still do workarounds I'm happy.
( I'm just slower to understand how it works but ContextGroup seems ok to me. )

That can work with Tomcat.current - it will just require adding a ContextGroup
property to Request and an Interceptor to set it, then Request will handle getSession
by calling the group's manager.

Costin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

costin@costin.dnt.ro wrote:
> 
> [...]
> But now we have a design that _enforce_ it - which is great, but doesn't allow any
> workaround ( well, except sharing between /a and /a/b ). 

It does, and more than the example you give. You can have apps with context roots
/a, /b and /c, and introduce a ContextGroup component (a Container) that contains
Context instances for /a, /b and /c. The ContextGroup has a Manager associated with
it so sessions are shared between the three contexts.

> I love to see the spec
> enforced, but remember me when you'll have to do a large site, that potentially
> spans multiple contexts ( like /hr/ , /eng/ , /sales/ ) - each developed independently.

That can be handled with the above approach, it's just a more concrete example
than my /a, /b and /c contexts.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

> Well, the way to share a Manager between multiple ("related") Contexts that I have
> suggested can be done with the Tomcat.next model is actually to associate the Manager
> with a Container, possibly named ContextGroup, higher up in the hierarchy. So that would
> be one case where the Manager is not associated with a Context.

Ok, let me step back - the reason I spent so much time arguing about Manager is
very simple.  I personally ( i.e. in my free time :-) feel that one of the biggest
problems with the current spec is that you the scope of the session is _required_
to be web application.

I'm sure smarter people concluded this is the only way to protect one application
from another ( unfriendly ) one. And everything is ok because nobody implements
this ( and as a matter of fact, there are not so many wars anyway).

But now we have a design that _enforce_ it - which is great, but doesn't allow any
workaround ( well, except sharing between /a and /a/b ). I love to see the spec
enforced, but remember me when you'll have to do a large site, that potentially
spans multiple contexts ( like /hr/ , /eng/ , /sales/ ) - each developed independently.
Apache is so great because it strictly respects the specifications, but also
allow people to do tricks and resolve their problems. See mod_rewrite...


Costin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

costin@costin.dnt.ro wrote:
> 
> >
> > Why does this matter?  Because the suggested approach (having the Manager call Context.getSessionTimeout) only
> > works when the container you attach the Manager to is actually a Context.  When it's not, what do you do?  I
> > prefer to think of a Manager as a black box, which can be configured as requried based on its own parameters,
> > but which also must support a setMaxInactiveInterval() method simply to provide the configuration method of a
> > Context a way to record the specified value.  After all (at least in the Tomcat.Next design) there is no
> > functional logic in a Context that depends on this setting - the only code that cares is the code that
> > implements Manager.createSession().
> 
> Speaking of "designing for unprobable situations" - I think "Manager shared between Contexts" is more usefull
> and more probable than "Manager attached to something else than Context".

Well, the way to share a Manager between multiple ("related") Contexts that I have
suggested can be done with the Tomcat.next model is actually to associate the Manager
with a Container, possibly named ContextGroup, higher up in the hierarchy. So that would
be one case where the Manager is not associated with a Context.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

>
> Why does this matter?  Because the suggested approach (having the Manager call Context.getSessionTimeout) only
> works when the container you attach the Manager to is actually a Context.  When it's not, what do you do?  I
> prefer to think of a Manager as a black box, which can be configured as requried based on its own parameters,
> but which also must support a setMaxInactiveInterval() method simply to provide the configuration method of a
> Context a way to record the specified value.  After all (at least in the Tomcat.Next design) there is no
> functional logic in a Context that depends on this setting - the only code that cares is the code that
> implements Manager.createSession().

Speaking of "designing for unprobable situations" - I think "Manager shared between Contexts" is more usefull
and more probable than "Manager attached to something else than Context".

Also, remember that we are not talking about timeout - but about few other parameters on which Manager may
depend ( context parameters, isDistributable ) - which do not "belong" to Manager, and are used by other
components too.

And finally - I like strong-typing, I prefer to use a Context when I'm talking about a context,
using Container for everything is not necesary good.

Costin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

"Craig R. McClanahan" wrote:
> 
> [...]
> > I don't follow; the Manager is not a Container according to the Tomcat.next proposal,
> > it's associated with a Container (most likely a Context). So I don't really see how
> > you comment is related to the question about if session related Context attributes
> > should be set explicitly be the owning Container (Context) or if it's better to
> > let the Manager ask for attributes when it needs them. Please clarify.
> >
> 
> It matters on two levels.
> 
> You are correct, the Manager is not a Container -- it is a component associated with a Container.  The reason I
> made this comment is that a Container need not be a Context.  Instead, it might be the container that represents
> the Apache web server (in an Apache-connected scenario), or it might be an Engine (singleton within Tomcat) or
> Host (virtual host representation) in a stand-alone deployment.  Neither of these types of containers support a
> getSessionTimeout() type method in Tomcat.Next, because they do not have a defined deployment descriptor
> architecture like a Context does.
> 
> Why does this matter?  Because the suggested approach (having the Manager call Context.getSessionTimeout) only
> works when the container you attach the Manager to is actually a Context.  When it's not, what do you do?  I
> prefer to think of a Manager as a black box, which can be configured as requried based on its own parameters,
> but which also must support a setMaxInactiveInterval() method simply to provide the configuration method of a
> Context a way to record the specified value.  After all (at least in the Tomcat.Next design) there is no
> functional logic in a Context that depends on this setting - the only code that cares is the code that
> implements Manager.createSession().

Okay, I see your point. And with my (late) realization that it's not enough to
change the "ask instead of being told" relation between Manager and Context to
get the flexibility Costing is after, I guess the interface should be as you
suggested initially.

So, we're back where we started. The same issue remains: Costin (and maybe others,
but I don't see anyone else joining this discussion) feel that it should be possible 
to share the same Manager between multiple Contexts, and your proposal enforces a 
one-to-one relationship (which I support). How can we resolve this issue. Anyone else 
have any ideas?

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

Hans Bergsten wrote:

> "Craig R. McClanahan" wrote:
> >
> > Hans Bergsten wrote:
> >
> > > PS.I still think it's a good idea to have the Manager ask the Context for
> > > attribute values (since it makes the interface more stable), but I would like
> > > to see a setContext() method instead of a setTimeout() method; and yes, this
> > > would enforce a one-to-one relationship between Manager and Context.
> > >
> >
> > The Tomcat.Next approach to sharing components between containers (be they for session management, logging,
> > security realms, or whatever) is the rule, embedded in the JavaDocs of each get method -- if you don't have
> > a component explicitly associated with yourself, return the one associated with your parent container.  So,
> > if you want globally shared components, just attach them at the highest level container in your particular
> > hierarchy (the special one for Apache connected, or the Engine one in an Engine/Host/Context approach), and
> > don't attach any override components (of that type) at lower levels.
> >
> > The basic concept is very much like subclasses selectively overriding methods of their superclasses, but
> > only if they need something different.
>
> I don't follow; the Manager is not a Container according to the Tomcat.next proposal,
> it's associated with a Container (most likely a Context). So I don't really see how
> you comment is related to the question about if session related Context attributes
> should be set explicitly be the owning Container (Context) or if it's better to
> let the Manager ask for attributes when it needs them. Please clarify.
>

It matters on two levels.

You are correct, the Manager is not a Container -- it is a component associated with a Container.  The reason I
made this comment is that a Container need not be a Context.  Instead, it might be the container that represents
the Apache web server (in an Apache-connected scenario), or it might be an Engine (singleton within Tomcat) or
Host (virtual host representation) in a stand-alone deployment.  Neither of these types of containers support a
getSessionTimeout() type method in Tomcat.Next, because they do not have a defined deployment descriptor
architecture like a Context does.

Why does this matter?  Because the suggested approach (having the Manager call Context.getSessionTimeout) only
works when the container you attach the Manager to is actually a Context.  When it's not, what do you do?  I
prefer to think of a Manager as a black box, which can be configured as requried based on its own parameters,
but which also must support a setMaxInactiveInterval() method simply to provide the configuration method of a
Context a way to record the specified value.  After all (at least in the Tomcat.Next design) there is no
functional logic in a Context that depends on this setting - the only code that cares is the code that
implements Manager.createSession().

>
> Hans

Craig

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

"Craig R. McClanahan" wrote:
> 
> Hans Bergsten wrote:
> 
> > PS.I still think it's a good idea to have the Manager ask the Context for
> > attribute values (since it makes the interface more stable), but I would like
> > to see a setContext() method instead of a setTimeout() method; and yes, this
> > would enforce a one-to-one relationship between Manager and Context.
> >
> 
> The Tomcat.Next approach to sharing components between containers (be they for session management, logging,
> security realms, or whatever) is the rule, embedded in the JavaDocs of each get method -- if you don't have
> a component explicitly associated with yourself, return the one associated with your parent container.  So,
> if you want globally shared components, just attach them at the highest level container in your particular
> hierarchy (the special one for Apache connected, or the Engine one in an Engine/Host/Context approach), and
> don't attach any override components (of that type) at lower levels.
> 
> The basic concept is very much like subclasses selectively overriding methods of their superclasses, but
> only if they need something different.

I don't follow; the Manager is not a Container according to the Tomcat.next proposal,
it's associated with a Container (most likely a Context). So I don't really see how
you comment is related to the question about if session related Context attributes
should be set explicitly be the owning Container (Context) or if it's better to
let the Manager ask for attributes when it needs them. Please clarify.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

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

Hans Bergsten wrote:

> PS.I still think it's a good idea to have the Manager ask the Context for
> attribute values (since it makes the interface more stable), but I would like
> to see a setContext() method instead of a setTimeout() method; and yes, this
> would enforce a one-to-one relationship between Manager and Context.
>

The Tomcat.Next approach to sharing components between containers (be they for session management, logging,
security realms, or whatever) is the rule, embedded in the JavaDocs of each get method -- if you don't have
a component explicitly associated with yourself, return the one associated with your parent container.  So,
if you want globally shared components, just attach them at the highest level container in your particular
hierarchy (the special one for Apache connected, or the Engine one in an Engine/Host/Context approach), and
don't attach any override components (of that type) at lower levels.

The basic concept is very much like subclasses selectively overriding methods of their superclasses, but
only if they need something different.

Craig

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session ManagerBase.java StandardSessionManager.java

[Hans Bergsten <ha...@gefionsoftware.com>]

costin@costin.dnt.ro wrote:
> [...]
> > Who creates new session objects?  If it's the session manager, then it needs to know the default
> > timeout to properly initialize the value returned by getMaxInactiveInterval().  In addition, if you
> > have an admin application adjusting the properties of a running web application, any changes to the
> > default session timeout need to be forwarded to the session manager as the default for subsequent
> > new sessions.
> 
> Or:
> The admin application will change the context properties, including default maxInactiveInterval.
> createSession() takes as parameter the Context - and SessionManager will ask for the current
> value. [...]

Wow, you almost had me there Costin ;-) But the comment above made me realize that
it's *not* enough to just let the Manager ask the Context for attribute values in
order to support your "shared Manager" model; you must also pass a Context as a
parameter in most (all?) methods. That's a bit hard to swallow without a very good
motivation.

> [...]
> What if a future version of the servlet API will allow related contexts to share
> session informations?  Yes, the current spec doesn't specify that, but spec
> changes - that's the very reason Tomcat code is so complex today !!!

Possible future spec changes like this is not a motivation that's good enough
IMHO. If such a change is made, I assume all the related contexts would have
to share session attributes, such as time-out, as well as other attributes.
You would most likely end up with a new concept, like ContextGroup, to hold
all the shared attributes. And there would be a one-to-one between the ContextGroup
and the Manager.

So besides major spec changes (which usually require a redesign anyway), what
is the motivation for sharing one Manager between multiple Contexts?

Hans
PS.I still think it's a good idea to have the Manager ask the Context for
attribute values (since it makes the interface more stable), but I would like
to see a setContext() method instead of a setTimeout() method; and yes, this
would enforce a one-to-one relationship between Manager and Context.
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com