commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gogineni, Pratima" <>
Subject RE: [digester] Portion of configuration handled by a different pr ocessor.
Date Tue, 15 Feb 2005 23:10:36 GMT
Thanks again for the input  Simon,

My scenario is that Im trying to embed the configuration necessary for a 3rd
party component in my configuration file (which means i dont want to
maintain the logic for parsing and creating the objects in my code since the
logic could change with upgraded versions of the component).

Our system configuration is stored in xml files that are parsed by the
digester. Then we decided to add the ability to enforce business rules by
using drools ( 

There could be one or more drools rule sets associated with each of our
system configuration objects that are created by the digester. We want to
store the rules in the same configuration file that is parsed by the
digester since the ruleset belongs to that object. But the parsing logic is
intrinsic to drools and we dont want to maintain that so I have to pass this
portion of the config xml to the drools classes to parse.


-----Original Message-----
From: Simon Kitching []
Sent: Tuesday, February 15, 2005 2:49 PM
To: Jakarta Commons Users List
Subject: RE: [digester] Portion of configuration handled by a different
pr ocessor.

On Tue, 2005-02-15 at 10:12 -0800, Gogineni, Pratima wrote:
> I think a custom rule class similar to the nodecreaterule will work in my
> scenario. The plugin still seems to assume that digester would be handling
> the rules for the plugin classes (even though we get the flexibility of
> adding these rules dynamically). 

Yes, using digester plugins means using digester rules to process the
associated xml input.

If your goal is to integrate code that *already implements* its own
initialisation code by parsing an input xml stream, then I expect
creating a custom rule to pass the xml to that object is the way to go.

Of course well-designed code really should separate configuration code
from the business-logic code. And the digester plugins package does that
quite cleanly. So if the plugin classes you are trying to integrate
don't yet have any configuration/initialisation code, I would recommend
a good look at plugins.



To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message