Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <387B7996.461AC42B@mytownnet.com>
Date: Tue, 11 Jan 2000 10:42:30 -0800
From: "Craig R. McClanahan" <cmcclanahan@mytownnet.com>
Organization: MyTown Network, Incorporated
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]
References: <Pine.SOL.3.96.1000111102714.27286R-100000@tallest>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Anil K. Vijendran" wrote:

> On Tue, 11 Jan 2000 costin@costin.dnt.ro wrote:
>
> > Does everyone agree that tomcat.core will have a dependency on DOM ?
> > ( tomcat.current doesn't - is this a feature we want for the new architecture?)
>
> Why? Is it because the interceptors are picked from server.xml and are
> configured in by core?
>

The current approach taken by the Tomcat.Next "Lifecycle" interface passes a DOM node
that you use to configure yourself.  The intent is that the Lifecycle pattern would
be generally used for setting up most Tomcat.Next components, but it's not required.

I'm not hung up on this approach, but the Tomcat.Current technique (convert the DOM
to an XmlTree and deal with that) seems like overkill when Tomcat requires an XML
parser to configure itself anyway -- you're pretty much guaranteed to have the DOM
interfaces hanging around as well.

>
> It would be nice if core didn't have a dependency. It makes core lesser
> embeddable. I'd like to see APIs that allow us to plug interceptors in and
> the server.xml file is read and then these APIs are called at startup
> time.
>

I'd be fine with alternatives that removed this dependency.  As the Javadocs for
Lifecycle state, I consider validating this choice to be a FIXME type issue.

>
> >
> > Costin
> >
>

Craig