You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matthijs Wensveen <mr...@wanadoo.nl> on 2004/07/27 15:01:57 UTC
Possibel contribution? System to keep a map of configured objects and
to plug in rulesets dynamically
Hello,
My company uses xml documents and digester to configure their
application at start-up. Usually we want a Map of configured objects at
the end of application initialization.
A problem we encounter often, is that the xml used in one application
differs to the xml used in another application. Sometimes we want to
configure DAO's, other times only Property objects, and even other
times, MailBeans and some application-specific object. We want to be
able to write different pieces of xml that configure the objects without
having to modify the digester that parses them.
We would like to contribute our code to the Digester project if possible
as we think it might be useful for other developers as well.
A short explanation of how it works follows.
We have written a set of RuleSets that can be plugged into a digester
object when needed, so that we can have a repository of often used
RuleSets and per-application custom RuleSets. Plugging a RuleSet into
the digester is also done in the xml document parsed by Digester, for
example:
<?xml version="1.0"?>
<config>
<digester-ruleset class="config.PropertiesRuleSet"
pattern="config/properties" />
<digester-ruleset class="config.MailBeanRuleSet"
pattern="config/mailbean" />
<!-- Example properties -->
<properties name="example1">
<property key="key1" value="value1" />
<property key="key2" value="value2" />
</properties>
<properties name="example2">
<property key="key1" value="value1" />
<property key="key2" value="value2" />
</properties>
<mailbean name="contactForm" class="ContactFormMail">
<to email="me@domain.com" name="Its Me" />
</mailbean>
</config>
Of course, the definition of the digester-ruleset classes can be done in
another xml document.
From the code you would do:
//Get the singleton instance of the ConfigDigester that is used
througout the application
ConfigDigester.getInstance().getDigester().parse("config.xml");
//Get the object from the Map of configured objects
Properties exampleProps =
(Properties)ConfigDigester.getInstance().getConfigObject("example1");
MailBean contactFormMailBean =
(MailBean)ConfigDigester.getInstance().getConfigObject("contactForm");
As you can see, an important aspect is that the MailBean object is kept
in the configObject Map, even after being popped of the stack by digester.
Let me know if this is useful for the Digester project, so I can provide
the source.
Best regards,
Matthijs Wensveen
Func. Internet Integration.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Possibel contribution? System to keep a map of configured objects
and to plug in rulesets dynamically
Posted by Matthijs Wensveen <mr...@wanadoo.nl>.
>Hi Matthijs,
>
>I think your rules-related extension to Digester is very similar to the
>digester "plugins" module. Would you mind reading the javadoc for the
>"plugins" package, and then explaining a little more about the
>differences between that and your code? I have placed a copy of the
>package-summary for plugins from the CVS head here:
>http://www.apache.org/~skitching/digester-plugins-package-summary.html
>
>I didn't quite understand the following paragraph. Could you explain a
>little more?
>
>
>>We have written a set of RuleSets that can be plugged into a digester
>>
>>
>>>object when needed, so that we can have a repository of often used
>>>RuleSets and per-application custom RuleSets.
>>>
>>>
>
>
>
This is a comment about plugins in general. You can have multiple levels
of plugin specificity, application-specific, company-specific,
domain-specific, not-specific-at-all-aka-generic. So very common plugins
can be found on the internet (hopefully), and very application-specific
plugins are written by yourself or your development team.
>The feature of being able to have the new parsing rules embedded in the
>document being parsed, rather than in a separate xmlrules file, isn't
>currently supported by the plugins module, but I don't think it would be
>too hard to add to that framework.
>
>If you were willing to integrate your code with the existing plugins
>code, and the result wasn't too large in size, I would be interested in
>seeing it integrated into Digester. Even if you aren't interested in
>that, any feedback about the features of the existing "plugins" module
>vs your requirements would be appreciated.
>
>The bit regarding the ConfigDigester seems more application-specific to
>me, and in my opinion less suitable for inclusion in digester core. But
>others on this list may well have a different opinion.
>
>By the way, the convention on most email lists (and definitely on this
>one) is to reply using "bottom-posting", where your comments are placed
>*beneath* the earlier ones. It makes it much easier to understand an
>email conversation when the email can be read top-to-bottom.
>
>Regards,
>
>Simon
>
>
>
Hello Simon,
Sorry, about the top-posting, I shall bottom-post from now on.
There are really not too much differences between the plugin package and
our classes. In our package, the 'plugins' are really just an
implementation of a subinterface of the RuleSet interface. The advantage
of that was that we didn't need to define an interface that specified
how to load the Rules. When a new RuleSet is added, addRuleInstances is
called and you can add your rules there. The pattern for which this
RuleSet is applicable is set through the pattern property, that is,
get/setPattern is defined in the subinterface of RuleSet that every
plugin must implement. Of course you can choose to ignore the pattern
property, just like you can ignore pathPrefix (in RuleLoader), although
the javadoc says that you shouldn't.
The plugin system that enables the loading of RuleSets is a plugin as
well because it implements the same interfaces, but there is the problem
of bootstrapping which is done in the main digesting application
(ConfigDigester in our case). But I reckon Digester's plugin system has
to deal with this too.
Indeed, the ConfigDigester singleton having a Map of config objects,
hasn't got much to do with plugins. I think it might be suitable as an
application example, showing how to maintain a collection of objects
after the xml file is parsed.
It is really cool to see how much our systems look like each other.
Makes me feel I can play with the big guys :D
Regards,
Matthijs.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Possibel contribution? System to keep a map of configured
objects and to plug in rulesets dynamically
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
[Please see bottom of email for response]
On Wed, 2004-07-28 at 02:44, Matthijs Wensveen wrote:
> Hmm, I think this may be comparable to the digester.plugins packages? I
> haven't been paying attention to Digester development for quite a while
> so I had never seen these packages.
> Of course, I am still willing to provide source code to anyone that is
> interested...
>
> Matthijs.
>
>
> Matthijs Wensveen wrote:
>
> > Hello,
> > My company uses xml documents and digester to configure their
> > application at start-up. Usually we want a Map of configured objects
> > at the end of application initialization.
> > A problem we encounter often, is that the xml used in one application
> > differs to the xml used in another application. Sometimes we want to
> > configure DAO's, other times only Property objects, and even other
> > times, MailBeans and some application-specific object. We want to be
> > able to write different pieces of xml that configure the objects
> > without having to modify the digester that parses them.
> > We would like to contribute our code to the Digester project if
> > possible as we think it might be useful for other developers as well.
> >
> > A short explanation of how it works follows.
> > We have written a set of RuleSets that can be plugged into a digester
> > object when needed, so that we can have a repository of often used
> > RuleSets and per-application custom RuleSets. Plugging a RuleSet into
> > the digester is also done in the xml document parsed by Digester, for
> > example:
> >
> > <?xml version="1.0"?>
> > <config>
> > <digester-ruleset class="config.PropertiesRuleSet"
> > pattern="config/properties" />
> > <digester-ruleset class="config.MailBeanRuleSet"
> > pattern="config/mailbean" />
> > <!-- Example properties -->
> > <properties name="example1">
> > <property key="key1" value="value1" />
> > <property key="key2" value="value2" />
> > </properties>
> >
> > <properties name="example2">
> > <property key="key1" value="value1" />
> > <property key="key2" value="value2" />
> > </properties>
> >
> > <mailbean name="contactForm" class="ContactFormMail">
> > <to email="me@domain.com" name="Its Me" />
> > </mailbean>
> > </config>
> >
> > Of course, the definition of the digester-ruleset classes can be done
> > in another xml document.
> > From the code you would do:
> >
> > //Get the singleton instance of the ConfigDigester that is used
> > througout the application
> > ConfigDigester.getInstance().getDigester().parse("config.xml");
> >
> > //Get the object from the Map of configured objects
> > Properties exampleProps =
> > (Properties)ConfigDigester.getInstance().getConfigObject("example1");
> > MailBean contactFormMailBean =
> > (MailBean)ConfigDigester.getInstance().getConfigObject("contactForm");
> >
> > As you can see, an important aspect is that the MailBean object is
> > kept in the configObject Map, even after being popped of the stack by
> > digester.
> > Let me know if this is useful for the Digester project, so I can
> > provide the source.
Hi Matthijs,
I think your rules-related extension to Digester is very similar to the
digester "plugins" module. Would you mind reading the javadoc for the
"plugins" package, and then explaining a little more about the
differences between that and your code? I have placed a copy of the
package-summary for plugins from the CVS head here:
http://www.apache.org/~skitching/digester-plugins-package-summary.html
I didn't quite understand the following paragraph. Could you explain a
little more?
> We have written a set of RuleSets that can be plugged into a digester
> > object when needed, so that we can have a repository of often used
> > RuleSets and per-application custom RuleSets.
The feature of being able to have the new parsing rules embedded in the
document being parsed, rather than in a separate xmlrules file, isn't
currently supported by the plugins module, but I don't think it would be
too hard to add to that framework.
If you were willing to integrate your code with the existing plugins
code, and the result wasn't too large in size, I would be interested in
seeing it integrated into Digester. Even if you aren't interested in
that, any feedback about the features of the existing "plugins" module
vs your requirements would be appreciated.
The bit regarding the ConfigDigester seems more application-specific to
me, and in my opinion less suitable for inclusion in digester core. But
others on this list may well have a different opinion.
By the way, the convention on most email lists (and definitely on this
one) is to reply using "bottom-posting", where your comments are placed
*beneath* the earlier ones. It makes it much easier to understand an
email conversation when the email can be read top-to-bottom.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Possibel contribution? System to keep a map of configured objects
and to plug in rulesets dynamically
Posted by Matthijs Wensveen <mr...@wanadoo.nl>.
Hmm, I think this may be comparable to the digester.plugins packages? I
haven't been paying attention to Digester development for quite a while
so I had never seen these packages.
Of course, I am still willing to provide source code to anyone that is
interested...
Matthijs.
Matthijs Wensveen wrote:
> Hello,
> My company uses xml documents and digester to configure their
> application at start-up. Usually we want a Map of configured objects
> at the end of application initialization.
> A problem we encounter often, is that the xml used in one application
> differs to the xml used in another application. Sometimes we want to
> configure DAO's, other times only Property objects, and even other
> times, MailBeans and some application-specific object. We want to be
> able to write different pieces of xml that configure the objects
> without having to modify the digester that parses them.
> We would like to contribute our code to the Digester project if
> possible as we think it might be useful for other developers as well.
>
> A short explanation of how it works follows.
> We have written a set of RuleSets that can be plugged into a digester
> object when needed, so that we can have a repository of often used
> RuleSets and per-application custom RuleSets. Plugging a RuleSet into
> the digester is also done in the xml document parsed by Digester, for
> example:
>
> <?xml version="1.0"?>
> <config>
> <digester-ruleset class="config.PropertiesRuleSet"
> pattern="config/properties" />
> <digester-ruleset class="config.MailBeanRuleSet"
> pattern="config/mailbean" />
> <!-- Example properties -->
> <properties name="example1">
> <property key="key1" value="value1" />
> <property key="key2" value="value2" />
> </properties>
>
> <properties name="example2">
> <property key="key1" value="value1" />
> <property key="key2" value="value2" />
> </properties>
>
> <mailbean name="contactForm" class="ContactFormMail">
> <to email="me@domain.com" name="Its Me" />
> </mailbean>
> </config>
>
> Of course, the definition of the digester-ruleset classes can be done
> in another xml document.
> From the code you would do:
>
> //Get the singleton instance of the ConfigDigester that is used
> througout the application
> ConfigDigester.getInstance().getDigester().parse("config.xml");
>
> //Get the object from the Map of configured objects
> Properties exampleProps =
> (Properties)ConfigDigester.getInstance().getConfigObject("example1");
> MailBean contactFormMailBean =
> (MailBean)ConfigDigester.getInstance().getConfigObject("contactForm");
>
> As you can see, an important aspect is that the MailBean object is
> kept in the configObject Map, even after being popped of the stack by
> digester.
> Let me know if this is useful for the Digester project, so I can
> provide the source.
>
> Best regards,
> Matthijs Wensveen
> Func. Internet Integration.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org