Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Date: Mon, 23 Apr 2001 17:00:01 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: tomcat-dev@jakarta.apache.org
Subject: RE: Store Proposal
In-Reply-To: <Pine.LNX.4.21.0104231541550.1357-100000@simona.wyn.org>
Message-ID: <Pine.BSF.4.21.0104231637580.38119-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 23 Apr 2001 cmanolache@yahoo.com wrote:

> > Besides, I can *guarantee* you that Costin won't like several aspects of
> > the org.apache.catalina.Store interface, because it has dependencies on
> > the other Catalina internal interfaces :-).
> 
> You know me very well :-)
> 
> Yes, I think the session manager should be a separate module, with minimal
> dependencies on other components.

Given that the 4.0 architecture exists, works fine, lasts a long time,
... what you'd want, then, is for the existing Catalina architecture to
fundamentally change in order to share this component.  I don't see any
benefit (to Tomcat 4.0) by making that change at this point in time.

Of course, it never did make any sense to me either :-), for a couple of
reasons:

* You're going to have significant functional and lifecycle
  dependencies even if you don't have direct API dependencies --
  modules and adpaters try to hide some of this but it doesn't go away.

* Making a session store (or a session manager, or a ...) shareable
  implies that the world wants more than one Tomcat in the long run.
  If they don't, then why bother?  Having an adapter just adds a layer
  of abstraction, with no benefits (see below re: "complexity").

> I also think that mod_jk should be a
> separate module, that will work with any container that provides an
> adapter ( and not only 3.3 or 4.0 btw ). 
> 

The C side of the connector could be shared, and perhaps low-level
protocols pieces of the Java side.  Above that, and the Java side has to
make lots of assumptions about the internals of the container you are
talking to.

But, of course, one has to wonder if we really want to carry forward the
single component that causes 90% of the user complaints and bug reports,
and is difficult for even experienced folks to configure ...

> ( and this has nothing to do with 3.3/4.0 architecure - but with
> beeing able to manage the complexity ).
> 

If we were writing in C, I'd agree whole-heartedly with your
approach.  But we're not.  Java provides other ways to manage complexity.

> 
> > You're going to have a very hard time, though, overcoming the
> > fundamentally different architectural world views on which the 3.3 and 4.0
> > designs are based.
> 
> As long as the session manager is not very dependent on the internal
> architecture - it should be fine, and work not only in 3.3 or 4.0. There
> are many good ways to process a request - and the session manager ( or
> jasper, or the connector ) shouldn't care about that. 
> 

I'm personally planning to focus on enhancing persistent session support,
distributed servers, and so on, for Tomcat 4.  Ripping apart something
that already works in order to make it meet your definition of shareable
doesn't help me accomplish that goal.

If someone else wants to spend the effort to try that, go for it.

> 
> Costin
> 


Craig