These responses are in the spirit of a poll and a mixture of what I'd *really* want, not so much what I think is feasible or a good short-term strategy.
On 7/13/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
A. Deprecate phoenix
-1 I'm taking issue with the term "deprecate" Either a conf file will work with phoenix or not. The failing with every container (I've seen) is that they make the conf file container-specific. Ironic indeed. In terms of actual replacements on phoenix (assuming we are talking about doing that)...
A1. Replace it with Plexus (http://plexus.codehaus.org/)
-0
A2. Replace it with another Avalon compliant container (name it)
-0
A3. Replace it with Felix (http://incubator.apache.org/felix/)
-0
B. Remove avalon
+1 (ideal world)
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
+1
Components to be adapted to the container (Avalon or other).
C. Remove Cornerstone
+1
C1. Remove cornerstone dependencies in favor of Jakarta commons libraries where available
+1
C2. Use MINA to replace sockets/connection dependencies
+0
C3. Import code from not replaceable libraries to James codebase (refactoring it to remove Avalon and anything else needed)
-0
D. Lifecycle and dependency management D1. Use JNDI everywhere (ala J2EE)
-1
D2. Keep Avalon interfaces but write our own mini container for non Top Level Components.
-1
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 setter or construction based
E5. Keep the ServiceManager as a property stored in the MailetContext.
-1
G. Dependency Injection G1. Use CDI (constructor base DI)
+0.5
G2. Use Setters
+1
G3. Use Setters with Enabling Interfaces
-1
G4. Keep single setter for ServiceLocator (ala Avalon)
-1
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
-0 -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
