Oki.... actually that is the basic reason for me looking into digester that deep. I'm still fumbling with the clustering stuff (And I tossed it in another package following Remys feelings about transactions and cluster in tomcat). However I need some way to plug into tomcat, I do that by creating a Manager. But as I need more configuration and more objects (to let the user choose if he wants a Multicast cluster (Bip's idea) or a RMI cluster or a JSpaces cluster or whatever, I need to add rules. I want to impact the ContextRuleSet class as little as possible so I searched for another way to plug myself in :-)
Ok, I go on coding. Cheers, Mika ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:30 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 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
