james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Spring deployment
Date Tue, 05 Jun 2007 10:12:55 GMT
Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>> While I think that a spring class to read the avalon descriptor is cool
>>  I also think it has a couple of drawbacks to take into consideration:
>> 1) the avalon descriptor is in the phoenix function: in the current ant
>> build you cannot make a function to depend on another functions. Maybe
>> Robert has a solution for this.
> I will base the work on
> https://svn.apache.org/repos/asf/james/server/trunk/phoenix-deployment/src/conf/james-assembly.xml
> We could easily move that into a generic conf module or so, if needed.

In future we'll probably split service classes from their own avalon
wrappers. In that eventuality we'll have to point Avalonized wrappers in
the assembly and POJOs in the spring xml.

Btw I see your "current proposal" more as a cool spring based avalon
container. So a replacement for Phoenix, while sticking to avalon.

+1 on this: if this could be kept as generic as possible I think that
also other avalon projects would be glad!

>> 2) Spring beans configuration is much more powerful than avalon assembly
>> descriptor, so reading the descriptor will give us big compatibility and
>> simplicity in moving to spring, but won't let us to use the more
>> expressive spring configurability.
> This is a walk into an open field, not a dead-end road.
> Spring offers many choices for configuring beans, not just XML.
> I intend to add 1 more choice. You still would have all possibilities to
> use additional and alternative configurations.
> The bean factory I will create is for pure convenience.
> This ia also regarding that we probably do not want to maintain 2
> syntactically different but semantically identical deployment
> descriptors (or even more if at some time someone creates a
> Guice/HiveMind/whatever deployments). It provides the most simple way of
> migration.



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

View raw message