Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <012e01c383d0$e0a51fa0$edd4fea9@radpbi.bah.com>
From: "Sgarlata Matt" <sgarlata_matt@bah.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <000701c38068$2ab8e3e0$7001a8c0@radpbi.bah.com>
 <20030921143832.E42422@minotaur.apache.org>
 <010801c3816e$6e4cabd0$edd4fea9@radpbi.bah.com> <3F6FA306.5010803@apache.org>
 <000001c3829a$1b30e6f0$c14b509c@radpbi.bah.com> <3F71CD73.3030609@apache.org>
Subject: Re: [Chain] DTD, Design Considerations,
 etc. (was Re: [Chain] examples XML file available?)
Date: Thu, 25 Sep 2003 21:52:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

(I'm less annoying in this email I promise...)
----- Original Message ----- 
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, September 24, 2003 12:59 PM
Subject: Re: [Chain] DTD, Design Considerations, etc. (was Re: [Chain]
examples XML file available?)


> Sgarlata Matt wrote:
>
> >The conversation threads are getting kind of crazy, so I'm going to skip
> >inline quotes for parts of this.
> >
> >Craig, now I do see your point about using the ConfigRuleSet to digest a
> >portion of
> >an arbitrary XML file.  That is very cool, and now I understand why the
> >names of the XML elements are configurable.  I always understood the
value
> >of letting attributes to the <command> element (and other elements).
This
> >is a much slicker approach than creating nested <set-property> elements.
> >Still, I think it could be useful to have a DTD for the *default*
behavior
> >of the ConfigRuleSet.  I think in general users will start off using the
> >default behavior, and then may at a later date decide to fold their
commands
> >into some other file, so a DTD will be nice to get people started with
the
> >Chain package.  I agree with most your points about the constraints I
placed
> >in the DTD being inappropriate, and will explicitly address each if we
ever
> >decide to make a DTD.
> >
>
> Unfortunately, none of the Command implementations I am interested in
> building into my Chains would be usable in a document parsed against
> such a DTD, for the technical reasons we discussed earlier.  Therefore,
> I'm not interested in any sort of DTD that someone would actually try to
> use in a validating parser.  If what you want is a more high level view
> of the typical structure of such a file (i.e. documentation), that's a
> different matter, and should be addressed with diagrams, examples, and
> how-to guides; minimally, to the level of detail you see in the "Package
> Description" docs for things like Digester and BeanUtils.

OK, maybe this weekend I'll submit a new package.html for review.  I give up
on the DTD ;)

> >How about making a Register class which is an implementation of Context
> >which stores only references to Catalogs?  We could make the registry
itself
> >a singleton, and write in design notes that since the registry is shared
> >between apps, each app should store its Catalog(s) in an
> >application-specific attribute like below:
> >
> >Registry
> >|
> >|---org.apache.struts
> >|---|---actions.RequestProcessor
> >|---|---somethingElse
> >|---com.bah.krm
> >|---org.apache.commons.something
> >
> >That's not explained incredibly well, but if each application component
> >reserves its own spot in the registry, we should be able to make the
> >registry a singleton everyone can share.  This keeps us from tying
ourselves
> >to the Servlet API, as was mentioned in the ChainServlet discussion
thread.
> >
> >
>
> It should be obvious that creating such a class is trivially simple, but
> you should first study how class loaders work in servlet containers, and
> then think about what happens if commons-chain were placed in a parent
> class loader (meaning that any singletons you try to create with static
> variables are shared across *all* webapps, not just the current one).
> The docs for Tomcat's class loader are specific to Tomcat, but typical
> of the architecture that most web containers offer:
>
>   http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

I understand this difficulty which is why I was thinking that if we make it
an explicit part of the API that you are supposed to store things in
such-and-such place that we could be in good shape.  In the example I gave,
I was trying to say that even if different apps used the same singleton,
they would all be isolated from each other by virtue of the fact that the
API tells them that they need to store everything under their own unique
attribute name, like com.mycompany.myprogram or org.apache.struts.  This is
like how Java can't guarantee two classes have the same name, but hopefully
if people follow the guidelines they are supposed to in terms of naming
their packages then name collisions will be less frequent.

> The other reason I didn't go here is that we're actually at the edge of
> the patterns that commons-chain was created to implement.  How it gets
> embedded into a particular application should be up to that application.
>
> Indeed, the only reason that Catalog exists is to allow chains to refer
> to other chains in an organized way.  One could argue that even this is
> out of scope; however, it's very useful to be able to write a Command
> that uses complex processing logic to decide which other commands (or
> chains, since you can't tell in the catalog what something is) should be
> used to actually perform a task.

Yeah, you're right.  I read WHITEBOARD.html and got very excited about
Agility, and really I think this type of registry idea might find a nice
home in Agility.  Who is working on this?  Is anything out there yet?  I'd
be very interested in contributing if so.

> Class libraries should be narrowly focused on as few fundamental ideas
> as possible, and then do them there.  They should not impose onerous
> restrictions on applications that want to use them (which is why the
> config package that uses Digester is optional -- you can compose chains
> any way you like).  The fundamental APIs we've defined so far (Command,
> Chain, Context, and Filter) are the minimum needed to implement the
> desired design patterns.  Catalog is on the edge, but useful for
> combining chains/commands in a controlled manner.  Registry is more
> about how catalogs would be accessed, rather than what they do.  Indeed,
> you don't even need such a thing in many environments; for example, a
> web app's ServletContext attributes do exactly what your registry does
> for that particular use case.

Yeah, this is a good approach that I don't have a lot of experience with.
I'm using BeanUtils and Digester freely without worrying about having
certain portions of my API tied to Struts, so thank you! :)

> >
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>