You might want to have some discussion on each item before calling for a
vote. In some of these cases, there may be alternatives to the choices you
listed.
> Example votes
-1 or +1 are the only meaningful votes at the ASF.
> A. Deprecate phoenix
+1 But in what timeframe? I am in no rush. Perhaps a year or more from
now, since I view the container as a means to an end, not an end in itself.
So long as we can keep improving what we really want to have, the container
isn't in the way. So we start to make the code container independent, and
take our time getting there, and when we are ready, we can move more
painlessly.
As for your A1, A2, A3, the only one I like is A3, but although that may be
the right direction for JAMES, we have to investigate it. And we should
still not pollute all of the code with tight ties to the runtime framework.
> B. Remove avalon
+1
But again, there is a migration strategy. First we remove it from where it
does not belong (e.g., Matchers and Mailets), and we incrementally do it
until we're ready to switch platforms.
Thing analog or shades of gray, not binary. This is like your desire to
remove code that can be deprecated. We don't need to push code off a cliff.
> B3. Remove it from all the codes and keep wrapper for Top Level
> Components to be adapted to the container (Avalon or other).
*EVENTUALLY*
C. Remove Cornerstone
Again, a process, not a cliff.
> C1. Remove cornerstone dependencies in favor of Jakarta commons
> libraries where available
+1
> C2. Use MINA to replace sockets/connection dependencies
-1 to replace. +1 to ADD new MINA versions that will EVENTUALLY replace the
current ones. Solution to this problem already outlined.
> C3. Import code from not replaceable libraries to James codebase
> (refactoring it to remove Avalon and anything else needed)
If necessary. What do you have in mind that is not replaceable?
D1. Use JNDI everywhere (ala J2EE)
Needs to be explored. Far too early to vote upon. For one thing, despite
how long it has been around, I suspect that few people know enough about
JNDI to cast an informed vote.
> D2. Keep Avalon interfaces but write our own mini container for non Top
> Level Components.
-1 as a policy, not code.
> D3. Introduce new interfaces to replace the one from Avalon and create
> our own container
Containers. Plural. We need to distinguish which containers we have, and
what would be appropriate for each. And the answers to the above questions
may be different for the Mailet Container vs other containers.
> E1. Use JNDI to lookup datasources
> E2. Use JNDI to lookup users/mail repositories, the store and
> any other James component.
Again, premature and possibly container dependent.
> 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)
Probably not. That would require the MailetContext to expand to understand
every possible service, and require every possible service. But some of
them? Perhaps.
> E4. Use Dependency Injection (setter based, constructor based, enabling
> interfaces, service locator injection) to automatically satisfy
> components dependencies.
Where? For the Mailet API? -1. Elsewhere in JAMES? To be determined.
E5. Keep the ServiceManager as a property stored in the MailetContext.
If you voted +X to something DI related please also vote this:
G. Dependency Injection
> Where? What what does it mean? Injection of a ServiceLocator is little
different from what a good container does with JNDI, since the
InitialContext can be dependent on whom is creating the InitialContext, and
the result is used to locate.
As a general rule, we can use DI (on selected setters or via the Context
pattern) to address the standard, expected, required, things. And
ServiceLocator (via JNDI) for other things that a container might not even
know about, but can be registered with it.
For example, using DI for the datasource is just wrong. It embeds in the
API the idea that there IS a notion of a datasource. That may or not not be
correct, and there may be MANY datasources that an admin wants to define.
> H1. Use Spring
-1
> H2. Use XBean
Premature. And where?
> H3. Use OSGi Declarative Services
This is my preferred direction. But does that mean that Mailets should be
OSGi components? No.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
