commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration][patch] Support for object creation
Date Tue, 07 Oct 2003 09:30:25 GMT
Oliver..

Sorry I missed your earlier post..  So, have you looked at the Digester
commons project?  I think it does similar to what your code does..  It takes
in an XML file with various rules about constructores etc and then builds
the objects from that.

There is also in (I think :-) ) beanutils a simple version of Digester that
hides away a lot of the complexity of digester..

Could you highlight how your code and digester are different? It seems also
that what you have done might be better applied to digester as a "simple"
xml format..

Lastly, would it make sense to write a digester friendly configuration
converter?  In otherwords, something that would take a configuration
objects, feed it to digester and get back objects?

Eric

> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Tuesday, October 07, 2003 11:08 AM
> To: Jakarta Commons Developer List
> Subject: [configuration][patch] Support for object creation
>
>
> Hello,
>
> I did not receive an answer on my last mail, but nevertheless
> created a
> patch which implements my suggestions (including a unit test
> class and a
> test configuration file; I only created new files and did not change
> existing sources).
> Maybe the code makes the intension clearer.
> Please tell me your thoughts!
>
> Regards
> Oli
>
> ----- Original Message -----
> From: "Oliver Heger" <Oliver.Heger@t-online.de>
> To: "Jakarta Commons Developer List" <commons-dev@jakarta.apache.org>
> Sent: Wednesday, October 01, 2003 12:05 PM
> Subject: [configuration] Support for object creation
>
>
> > Hello configuration developers,
> >
> > I am quite new to open source and would like to contribute
> something to
> this
> > project. I was working on a proprietary configuration
> framework and maybe
> I
> > can share some of the ideas used there with the community.
> >
> > At first I'd like to suggest a simple but (as I hope)
> useful extension for
> > creating objects based on configuration information. As a
> use case for
> this
> > consider an application that accesses some central
> components (e.g. a
> > resource manager, a caching component or whatever) only
> through interfaces
> > and at startup instanciates objects of implementation
> classes defined in
> the
> > configuration. This makes it possible to alter the
> application's behavior
> by
> > just changing an implementation class in the configuration;
> it is a kind
> of
> > application of the GoF strategy pattern.
> >
> > The idea is that information about a class is specified in
> a configuration
> > file as shown in the following example (for the XML flavour):
> >
> >   <myclassproperty>
> >     <class>mypackage.MyClass</class>
> >     <args>
> >       <property>Value</property>
> >       <anotherproperty>Another value</anotherproperty>
> >       ...
> >     </args>
> >   </myclassproperty>
> >
> > Then a new class of the configuration package named
> ObjectConfigData (or
> > somebody comes up with a better name?) can be used to read this
> > configuration and create an instance of the defined class:
> >
> >   Configuration config = ...
> >   ObjectConfigData objData = new ObjectConfigData(config,
> > "myclassproperty");
> >   Object obj = objData.createInstance();
> >
> > ObjectConfigData would extract the name of the class to be
> instantiated
> from
> > the class property below the specified configuration key
> and also all keys
> > in the content of the (optional) <args> element. It could
> use BeanUtils to
> > initialize the newly created instance with the properties
> defined here. So
> > the new instance can be parametrized.
> >
> > In addition to this initialization a Configurable (or
> similar) interface
> can
> > be defined with a single initialize method that takes a
> Configuration
> object
> > as argument. ObjectConfigData could check if the new
> instance implemented
> > that interface and if so, pass the whole content of the
> <args> section to
> > this method. This allows for a more sophisticated initialization.
> >
> > There are of course some details which need a further
> discussion (e.g.
> > exception handling), but I hope you get the point. (And I
> hope this mail
> is
> > not too long.) Your comments are welcome!
> >
> > Greetings
> > Oli
> >
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message