tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject RE: Store Proposal
Date Tue, 24 Apr 2001 02:15:34 GMT
On Mon, 23 Apr 2001, Craig R. McClanahan wrote:

> > 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.

Well, for tomcat4.0 probably not ( stability is more important than almost
anything else ), but 4.0 will no be (probably) the last tomcat.

More dependencies on internal details - the harder it is to evolve, harder
it is to split the work, or to get more people involved.

So I would say maximizing the modularity is good for tomcat, even if not
particulary for 4.0. 



> * 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.

The goal is not to eliminate API dependencies - but to reduce 
the coupling between components. A session mananger needs to be integrated
with a container - but what it expects and what it provide should be
clearly defined.

With a good design it may even be possible to make it usable as a
user-space program ( or in an arbitrary container ). 

Given the complexity of a good store I think it would be a good thing.


> * 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").

In the long run is very likely there will be more than one tomcat - this
is an open source project, and revolutions are possible at any time.

Even without revolutions, most software tends to evolve - tomcat4.1 or 5.0
might not have the same internal architecture with 4.0.


> > 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.

Well, let's not argue about this yet - probably very soon we'll have some
real code we can discuss, and I think clean separation between container
and connector is not that difficult.



> 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 ...

That's exactly the reason ! This kind of code takes a lot of time to
stabilize and mature - there are so many small things that need to be
taken into account.  Think about IIS/NES/Apache1.3/Apache2.0/AOLServer, 
about Windows, Mac, Netware, Unixes, about static vs. dynamic builds,
about all the load balancing problems.

And then you have the integration - authentication, etc - some people are
happy with forwarding all requests and let tomcat authenticate, but some
have existing infrastructure and need to tune to their needs.

I personally think this kind of things take a lot of time and effort to
mature and stabilize - mod_jk is close to 1 year old, and the most used
components ( ajp12, apache connector ) are almost there. Probaby it'll be
another year before JNI and the ajp14 will get similar amount of testing.


> > ( 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.

Well, I'm a bit more pesimistic. I've spent (too much) time with tomcat3.0
and I've worked with Apache's C - I don't think the language can do all 
the magic ( even if java provides better ways )

Featurism is a hard disease, and java is not imune to that - systems
do get more and more complex, and the only cure is good modularity. 


> 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.

:-)

Well, I'll focus on improving the modularity of 3.3 ( yes, I'm still not
happy, I still thing it can be improved - mostly the ProfileLoader module
and the config modules), and when the session manager is stable enough I
can volunteer to refactor it as a 3.3 module.

Costin




Mime
View raw message