Steve Brewin wrote:
<snip/>
Applying the same approach to James - "a complete and portable enterpriseA big non binding +1 to that!
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.
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?
+1
Caveat 3: There is no CDI standard or reference implementation. For example,"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.
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!
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 compatibility.
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.
Alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
