Noel, I respect you very much, but please no JNDI configuration this throws all POJO efforts away - again ALL (not the some but ALL) objects requiring configuration have to now about external entity. That is bad and does not give CDI IoC benefits.
I don't agree. we may have to have SOME bootstrap services which know how to get config from JNDI and config other services.
Apart from that JNDI isn't some hole-in-the-corner secret it is part of J2SE and we don't need a container to provide JNDI, we can provide our own.
As for commons-configuration it is like logging in a sense it is supposed that every class on earth should use one and only configuration method "commons-configuration", but in CDI IoC itself configuration idea is built-in and no external library/framework/whatever is needed to configure a collection of POJOs built with CDI IoC in mind.
That is OK if you assume that there are no configurable options that you might wish to change at start up or runtime.
We do see some separation of "binding times" for configuration. a) Assembly configuration asks, what objects should be instantiated to satisfy a requirement for a service implementation. b) Operational configuration asks what parameters should be supplied to instantiated services in order to modify their behaviour at runtime.
We are likely to see two different classes of user attending to the two different areas, and if there are two different approaches then that is not necessarily a bad thing. Let IoC take care of "a" but provide a simple mechanism for users to attend to "b".
Or not? What do you think?
Danny! I invite you to read Martin Fowlers article on IoC especially in the part where he explains the benefits of CDI versus Setter Dependency Injection.
http://www.martinfowler.com/articles/injection.html#ConstructorVersusSetterInjection
<quote>
My long running default with objects is as much as possible, to create valid objects at construction time. This advice goes back to Kent Beck's Smalltalk Best Practice Patterns: Constructor Method and Constructor Parameter Method. Constructors with parameters give you a clear statement of what it means to create a valid object in an obvious place. If there's more than one way to do it, create multiple constructors that show the different combinations.
</quote>
Which means to me: do not create object that have to states: created and initialized, rather do it in one place: constructor.
If you need a runtime change in configuration or rather behaviour you should write a component that supports such change and depend your component on the runtime-changable-component.
For example:
While running pop3 server some users have to be authorized in JDBC and other in LDAP. You write a class ChoiceUserStore that implements UserStore interface, accepts an array of UserStore objects in constructor and does the choice of concrete UserStore in runtime. Then you pass ChoiceUserStore to your POP3Server as a dependent component and forget about runtime configuration because it is transparent to your POP3Server.
For reference please check out the http://devel.priocom.com:8083/viewrep/JamesNG/core/src/net/ukrpost/store/SequenceUserStore.java and http://devel.priocom.com:8083/viewrep/JamesNG/core/src/net/ukrpost/store/MultiUserStore.java bundled with JamesNG
Also I have written a simple CDI IoC Quick Start Guide http://devel.priocom.com:8081/display/JamesNG/CDI+IoC+Quick+Start+Guide
d.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
