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? Cheers, Mika ----- 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]>
