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
