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/
