tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Date Tue, 26 Feb 2002 08:27:59 GMT

----- Original Message -----
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
Sent: Monday, February 25, 2002 11:18 PM
Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

> > > An additional, more subtle, cross-package dependency is probably also
> > > there -- assumptions about the implemented functionality, or the
> expected
> > > order of method calls, that might not always be clearly stated in the
> > > method JavaDocs.  We'll want to review the code for these kinds of
> > > as well.
> >
> > This is the one that really bit me in porting ApacheConfig to 4.x.  And,
> as
> > a result, the 4.x ApacheConfig suffers from the same problem of making
> > assumptions about the order of method calls.  Saying that they might
> > always be clearly stated in the method JavaDocs" is a gross
> understatement.
> > Roughly half the time, the "start" event is fired at the beginning
> (allowing
> > Listeners to change the config), and half the time it is fired at the
> > (allowing Listeners to react to the config).  IMHO, the 3.3 event model
> > an improvement: where you have an "init" event (fired at the beginning
> > the start method), and a "start" event (fired at the end of the start
> > method).
> It's not random, actually. The start event is sent to the listeners at the
> end of the ContainerBase.start method, which is right after all the
> have been started.
> The only problem is with the server and service, where the start event is
> sent before (so it's not really useful except to configure things).
> Adding a before-start event and before-stop event is doable IMO.

You've basically confirmed what I said above.  StandardHost &
StandardContext are subclasses of ContainerBase.  StandardServer & and
StandardService aren't. 50/50.  While I (personally) like what the current
4.x API forces me into (which I currently use complex 'sed' scripts to
achieve with 3.3's ApacheConfig), I think that I'm in a very small minority.
If it were possible to have a single Listener on the Server to do everything
(and, even better, only when asked to [@see jkconf in 3.3]), I think that
the ${Server}Config classes would be more popular.  I've never pressed for
this for the simple reason that JK2 has it's own auto-config, and changing
the API in the 4.0 branch is dangerous.  I just assumed that it would
resolve itself with the release of 4.1.
> Remy
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message