Stefano Bagnara wrote:
And now the bulk questions:
A. Deprecate phoenix
-0 in the short term (an year)
A1. Replace it with Plexus (http://plexus.codehaus.org/)
+0 Plexus seems to be actively developed (for maven2) and supports
avalon components and more (must be investigated).
A2. Replace it with another Avalon compliant container (name it)
-0 After excluding Loom and having upgraded to the latest Phoenix I
don't see other plausible containers.
A3. Replace it with Felix (http://incubator.apache.org/felix/)
-0 in the short term because OSGi will increase the time to become
confortable with the application. +0.5 in the long term
B. Remove avalon
-0 I feel good with Avalon, imho we can remove some of its pattern
(ServiceManager) and keep the basic interfaces.
B1. Remove it from "API Components"
+0.2 if we introduce a james specific DI to supports this components and
add Lifecycle to the component API.
B2. Remove it from both API Components and Other James Components
-0.5 nonsense: I prefer B1 or B3.
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
-0
C. Remove Cornerstone
+0.2 but I will vote each change library per library.
C1. Remove cornerstone dependencies in favor of Jakarta commons
libraries where available
+0.5
C2. Use MINA to replace sockets/connection dependencies
+1 I don't have problem with java 1.5 requirement for James 3.0 and I
think we should try to deprecate old code (less code to mantain, less bugs)
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
-0 I would do this only for Excalibur components (Avalon specific) if we
decide to remove Avalon from everywhere.
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)
-1
D2. Keep Avalon interfaces but write our own mini container for non Top
Level Components.
+1 I would keep Avalon lifecycle and logger. Eventually change
Configuration and ServiceManager in favor of a different COnfiguration
mechanism and DI for single services (remove Service Locator).
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.2 If they have to be identical to Avalon interfaces I'd keep Avalon ones.
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
-0 I'm still undecided about this: I think that using DI would be better.
E2. Use JNDI to lookup users/mail repositories, the store and any other
James component.
-0.5
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)
-0 The API would grow a lot and we'll limit extensibility.
E4. Use Dependency Injection (setter based, constructor based, enabling
interfaces, service locator injection) to automatically satisfy
components dependencies.
+1 Imo the right way
E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.9 Imho this is a bad practice and introduce a "hidden" dependency.
If you voted +X to something DI related please also vote this:
G. Dependency Injection
G1. Use CDI (constructor base DI)
-0
G2. Use Setters
+0.8
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 (even if we may need to add configurability for advanced setups)
Furthermore these technologies could be used to sole one or more aspects
of the above points, please give your opinions.
H1. Use Spring
-0.5 Not avalon friendly, too much xml configuration, big dependency.
H2. Use XBean
-0.5 I'd like to see what path is followed by Geronimo and Directory in
this aspect. I would not be an early user.
H3. Use OSGi Declarative Services
-0 There is much going on under the hood of OSGi services. iPOJO may
become interesting, but this is all new stuff and we have a small
developer community, we should learn from others.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
