james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Zhukov <zhu...@ukrpost.net>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Wed, 02 Feb 2005 17:49:25 GMT
Danny Angus wrote:
>>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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 


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


Mime
View raw message