On Thu, 13 Dec 2001, Mika Goeckel wrote:
> Date: Thu, 13 Dec 2001 01:25:22 +0100
> From: Mika Goeckel <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: Re: Self configuring Objects or is it possible to change the
> rule set during the parse phase?
>
> Hey fast man! :-)
>
> Yes, I've figured out how to extend digester to call that sort of method i
> was after. And I found the problem you mentioned.
> A way around that would involve passing the match variable to the rules. An
> object then would have it's position in the tree.
>
> The goal I'm after is to enable developers to add new subtree-rules without
> having to change and recompile the core code of tomcat for example.
> A side effect would be that it would be possible to better capsulate the
> configuration. Now all created classes are coupled to the startup.* classes
> that set the configuration.
>
> If I would provide the code, how would I get it in? Is commons organised
> like tomcat with vote?
>
Yes, it is, but I cannot imagine anyone turning down enhancements to
Digester (like a specialized match variable) that didn't break backwards
compatibility.
Note that any change to Tomcat's startup classes
(org.apache.catalina.startup.*) would have to be proposed to TOMCAT-DEV,
not here.
> Cheers, Mika
>
Craig
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, December 13, 2001 1:13 AM
> Subject: Re: Self configuring Objects or is it possible to change the rule
> set during the parse phase?
>
>
> >
> >
> > On Thu, 13 Dec 2001, Mika Goeckel wrote:
> >
> > > Date: Thu, 13 Dec 2001 00:35:58 +0100
> > > From: Mika Goeckel <[EMAIL PROTECTED]>
> > > Reply-To: Jakarta Commons Developers List
> <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Self configuring Objects or is it possible to change the rule
> > > set during the parse phase?
> > >
> > > Hi!
> > >
> > > Is it possible to add rules to the ruleset of a digester after the
> > > parse has been started? The reason for that is, that it would enable
> > > us to put the knowledge about child objects within something like a
> > > configure() method of a just created object.
> > >
> > > For example if someone creates a complicated valve with subobjects in
> > > tomcat, the knowledge that a valve needs to be created is for example
> > > in org.apache.catalina.startup.ContextRuleset. Now if someone needs a
> > > Valve with subobjects configured via digester he/she has to change the
> > > ContextRuleset class.
> > >
> >
> > It would be technically feasible to add new rules as you suggest.
> > However, I'm not sure it would really meet the goals you are after. In
> > your example, let's say that a particular Valve had a subobject named
> > "Foo". You could then conceivably add a new rule that matched the pattern
> > "Server/Service/Engine/Host/Context/Valve/Foo" -- but this would match a
> > "Foo" subelement on *any* Valve, not just the particular one you are
> > configuring. You'd need to be very careful about having unique subelement
> > names, or define your own Rules matcher that matched the above pattern
> > *only* if the className attribute of the Valve was the one you were
> > looking for.
> >
> > > If it would be possible to call a configure method on the specific
> > > implementation of a class, it could itself add the rules for childs.
> > >
> > > A class could implement a ProvideRules interface defined in the
> > > digester package to let the digester know that it wants to provide
> > > additional rules.
> > >
> > > Comments please?
> > >
> >
> > The approach I took in the Workflow project (in jakarta-commons-sandbox
> > right now) was to let the application configure all the RuleSet entries it
> > wanted before starting the parse in the first place. That seems to deal
> > with most of the use cases I've run into so far.
> >
> > Craig
> >
> >
> >
> > --
> > 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
