On 13/07/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
A. Deprecate phoenix A1. Replace it with Plexus (http://plexus.codehaus.org/)
+0
A2. Replace it with another Avalon compliant container (name it)
-1
A3. Replace it with Felix (http://incubator.apache.org/felix/)
+1 (eat your own dog food)
B. Remove avalon B1. Remove it from "API Components"
+1
B2. Remove it from both API Components and Other James Components
+0
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
+1
C2. Use MINA to replace sockets/connection dependencies
+1
C3. Import code from not replaceable libraries to James codebase (refactoring it to remove Avalon and anything else needed)
+0
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)
+1
E. Specific API Components issues: E1. Use JNDI to lookup datasources
+1
E2. Use JNDI to lookup users/mail repositories, the store and any other James component.
+1
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)
+1
E4. Use Dependency Injection (setter based, constructor based, enabling interfaces, service locator injection) to automatically satisfy components dependencies.
+1
E5. Keep the ServiceManager as a property stored in the MailetContext.
+0
If you voted +X to something DI related please also vote this: G. Dependency Injection G1. Use CDI (constructor base DI)
-1
G2. Use Setters
+1
G3. Use Setters with Enabling Interfaces
-1
G4. Keep single setter for ServiceLocator (ala Avalon)
-0
G5. Use reflection and convention over configurations for the above DI
-1
Furthermore these technologies could be used to sole one or more aspects of the above points, please give your opinions. H1. Use Spring
+1
H2. Use XBean
+0
H3. Use OSGi Declarative Services
+1
Stefano PS: I'm willing to track this thread and produce an (i hope unbiased) overview of the result. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
