----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
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
cases
> > > 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
"not
> > 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
end
> > (allowing Listeners to react to the config). IMHO, the 3.3 event model
is
> > an improvement: where you have an "init" event (fired at the beginning
of
> > 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
children
> 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:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
