On Mon, 25 Feb 2002, Bill Barker wrote:
> Date: Mon, 25 Feb 2002 23:00:07 -0800
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, February 25, 2002 6:25 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).
>
When looking at what it took to set up Catalina's connectors for the "run
as root" scenario, we came to the same conclusion -- ideally, Lifecycle
should have included an init() method, and probably a destroy() method as
well. At the time we looked, there would have been roughly 40 classes
that would need the new methods, plus calls to them in a bunch more, so we
chickened out and only implemented init() on the connectors themselves.
I'm game to look at this more broadly, but the number of changes required
to implement it is pretty significant.
> As I said, this is IMHO. Attempts to start a flame-war will be quietly
> ignored.
>
+1.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
