Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 51736 invoked by uid 500); 12 Aug 2003 18:11:31 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 51698 invoked from network); 12 Aug 2003 18:11:30 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by daedalus.apache.org with SMTP; 12 Aug 2003 18:11:30 -0000 Received: from pacemetrics.plus.com (HELO yahoo.co.uk) (james?strachan@81.174.226.122 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Aug 2003 18:11:34 -0000 Date: Tue, 12 Aug 2003 19:11:29 +0100 Subject: Re: Volunteers - Topics AND Configuration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: James Strachan To: geronimo-dev@incubator.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <655FDFC8-CCF0-11D7-A504-000A959D0312@yahoo.co.uk> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N FWIW shouldn't components and services be configured by the container - rather than the components being dependent on some arbitrary Config interface? i.e. inversion of control should apply to configuration as well. The container should do all of that and the component developer shouldn't need to know how to do it or have any special APIs to worry about etc. Then whether JNDI, MLETs, config files or whatnot were used by the container to configure components - that would be the containers choice. Component developers wouldn't have to worry about it. (The only thing a component developer may wish to do is validate its configuration at some point in the lifecycle - such as throwing an exception if a dependency hasn't been set yet - it shouldn't need to pull its configuration data out of some container-specific API). On Tuesday, August 12, 2003, at 06:41 pm, Henri Yandell wrote: > > I think they should be separate. The Configuration code will [I hope] > be > users of the JNDI code. It's something I've found myself tending > towards. > A JNDI implementation, but I often write a simple Config class around > that > JNDI back end. Simple things like: > > getAsString > getAsInteger > getAsFile > > etc etc, which keeps the code using the configuration a bit cleaner. > More > importantly, they are separated. > > My belief is that other parts of the system using the Configuration > should > do so through an interface. etc etc, OO OO, polywossism usw. > > Hen > > On Tue, 12 Aug 2003, Sean Hamblett wrote: > >> Hi, >> >> I am interested in Configuration, is that considered part >> of JNDI, or has that yet to be established as its own >> topic? Oh yeah, a little about me, Java/J2EE Developer 3 >> years with a couple years of C/C++ prior. >> >> Regards, >> >> Sean >> > > James ------- http://radio.weblogs.com/0112098/