james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Container direction for James
Date Thu, 02 Dec 2004 23:19:05 GMT
Steve Brewin wrote:


>Applying the same approach to James - "a complete and portable enterprise
>mail engine solution based on currently available open protocols"
>(http://james.apache.org/index.html) - we could detach the James solution
>from its reliance on a specific and dead container environment (Phoenix)
>and, if we wished, establish a Commons of mail components from which the
>James solution is assembled but others might leverage in their own ways.
A big non binding +1 to that! 

Over at the directory project once I stopped wrestling with Avalonisms 
for whatever container was the choice that week I got a huge boost of 
productivity.  This came just from begin able to better and faster 
test/debug the server.  The simplicity of POJIs and POJOs just brought 
me back to basics.  Following Paul's approach is refreshing.  After the 
big rush of independence I realized I spent months wrestling with 
container issues.  Also potential contributers were scared of Avalon and 
more so the container at hand.  Even if perspective contributers knew 
their stuff regarding Java and LDAP the container hurdles were just not 
worth getting over. 

I bet the James community realize this same expense! 

>Having a formal Commons of mail components is a philosophical shift for
>James. In my view a good one as it makes our code more accessible and
>contributing components easier. Others may have differing views?

>Caveat 3: There is no CDI standard or reference implementation. For example,
>dependency resolution. This is not a problem when explicitly declaring
>dependencies, but to me explicit declaration is simply moving a problem
>whereas "auto-wiring" (automatic resolution of dependencies) solves it.
>Except that the "auto-wiring" algorithms of CDI containers can yield
>radically different results!
"Auto-wiring" I quickly learned is overrated for us over at directory.  
Perhaps it may be the same for any almost static wiring of a server.  
Really there's very little glue code that's needed to connect the peices 
of Eve.  I realized its not worth the pain and wrote a factory that 
assembles a configuration for me using just hard wired code making 
debuging assembies easier.  All deps go into constructors as you pointed 
out.  If I need another configuration I just implement another factory.  
I have not had to do that yet.   So I don't think server projects really 
get a big bang out of this service. 

However there may be exceptions. If you have components that users can 
add and configure within the server the better approach IMO would be to 
integrate a framework or enable components of an existing framework in 
your server like the way Geronimo has with its Spring component 

These are just my experiences (my $0.02) and I'm no authority for sure.  
Just have been swimming in common problems for some time now.

Good luck with respect to these persuits.  Can't wait to see the 
direction the James community decides to take here.


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

View raw message