Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 98817 invoked from network); 7 Oct 2003 09:30:46 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 7 Oct 2003 09:30:46 -0000 Received: (qmail 37554 invoked by uid 500); 7 Oct 2003 09:30:16 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 37492 invoked by uid 500); 7 Oct 2003 09:30:16 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 37477 invoked from network); 7 Oct 2003 09:30:15 -0000 Received: from unknown (HELO hqexch01.upstate.com) (205.160.101.145) by daedalus.apache.org with SMTP; 7 Oct 2003 09:30:15 -0000 Received: from IQUITOS (davidlaptop.ltd.upstate.com [172.17.1.106]) by hqexch01.upstate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4GY7XSG2; Tue, 7 Oct 2003 05:31:03 -0400 Reply-To: From: "Eric Pugh" To: "'Jakarta Commons Developers List'" Subject: RE: [configuration][patch] Support for object creation Date: Tue, 7 Oct 2003 11:30:25 +0200 Message-ID: <007101c38cb5$a3e7c2f0$0100a8c0@IQUITOS> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001501c38cb2$7431e480$0101a8c0@eric> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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" > To: "Jakarta Commons Developer List" > 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): > > > > > > mypackage.MyClass > > > > Value > > Another value > > ... > > > > > > > > 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) 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 > 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