On 7/13/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Hi all,
This is a test, I hope it will work because I don't see another simple
solution to move forward from the current stall.
It's a vote, not a test, isn't it? ;-)
I'm starting this vote because I saw that there is a lot moving around
this issue and we probably currently don't share a common idea, so it's
better to see what the preferences/likes/dislikes/vetoes are in the
various aspects of this issue.
+1
The votes are many and are not clearly organized, but I hope this will
give us a first overview on the things where we have agreements and
things that may be discussed more. We have a broad range of
possibilities for our architecture, so we should try to narrow the real
options that will not be vetoed and get more consensus.
Maybe it would have been better to split this up into a voting-cascade
instead of trying to catch it all in one vote. But here we go...
And now the bulk questions:
A. Deprecate phoenix
A1. Replace it with Plexus (http://plexus.codehaus.org/)
A2. Replace it with another Avalon compliant container (name it)
A3. Replace it with Felix (http://incubator.apache.org/felix/)
+0 to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
B. Remove avalon
B1. Remove it from "API Components"
+1
B2. Remove it from both API Components and Other James Components
+1
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
+1
C. Remove Cornerstone
C1. Remove cornerstone dependencies in favor of Jakarta commons
libraries where available
C2. Use MINA to replace sockets/connection dependencies
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
+1 C1-C3, but I consider this to be a very long time project, curretly
more of the visionary type. I have many sympathies for starting with
MINA soon.
Now I expect that many will have replied +X to A3 or at least to one of
the B*, so here are further votes related to this scenario.
D. Lifecycle and dependency management
D1. Use JNDI everywhere (ala J2EE)
-0
D2. Keep Avalon interfaces but write our own mini container for non Top
Level Components.
-0
D3. Introduce new interfaces to replace the one from Avalon and create
our own container (that may delegate to the real container we use) to
manage lifecycle and dependencies. (see also "Central class for service
injection" topic by Bernd)
+0 (I see my proposal only as an intermediate step on the way to
reduce Avalon deps)
D4-BF. Use some simple, lightweight form of (auto-)wiring, there must
be something out there (if not XBeans)
+1
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
E2. Use JNDI to lookup users/mail repositories, the store and any other
James component.
E3. Add datasource, repositories, store and any other used service to
the MailetContext API (this also mean adding the interfaces for this
objects to the Mailet APIs)
tough question. my brief insight into this topic tells me that it's
very wrong how it is today, but exposing the interfaces directly?
_That's_ where I'd like to see JNDI!
But I don't think I am aware of enough discussion concerning this
topic to vote it.
E4. Use Dependency Injection (setter based, constructor based, enabling
interfaces, service locator injection) to automatically satisfy
components dependencies.
+1 (but I'm also +1 to _optionally_support_ JNDI)
E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.5
G. Dependency Injection
G1. Use CDI (constructor base DI)
G2. Use Setters
G3. Use Setters with Enabling Interfaces
+1 G1-G3, I am not enough a religious DI fanatic to exclude any of those
G4. Keep single setter for ServiceLocator (ala Avalon)
-0 all other options are superior
G5. Use reflection and convention over configurations for the above DI
+0,5
Furthermore these technologies could be used to sole one or more aspects
of the above points, please give your opinions.
H1. Use Spring
H2. Use XBean
H3. Use OSGi Declarative Services
+1 H1-H3 (sigh, if we only where _that_ far already, I'd take any of these :-) )
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
