Danny Angus wrote:
My proposal is that we do indeed move a whole lot of our service
interfaces.
But... (read this first before replying...)
We need to have an extensible mechanism which allows 3rd parties to
add services, which means that we're really talking about using JNDI
I think it is "in-topic" to revamp part ot the result of a POLL I
started 3 months ago ([VOTE] Wiring/Dependencies/Lifecycle Management
for next James). I see you didn't write your opinion, so you can add
them now to update us on your preferences.
To be clear I think we all consider this "votes" as preferences and not
as a real vote (it was made clear on the vote thread that it was more a
POLL than a vote), but I think it is important to keep this in mind if
you're working on a proposal and you're looking for consensus ;-)
-----
B1. Remove Avalon from "API Components"
+0.2 Stefano - if we introduce a james specific DI to supports this
components and add Lifecycle to the component API.
+1 Bernd
+0.8 Soren
+0.8 Norman - That whould be cool.. I don't like the idea of need
knowing about avalon to write mailets or smtphandler etc..
+0.8 Vincenzo
+1 Serge
------
So I think we all agree on this.
-------
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
-0 Stefano - I'm still undecided about this: I think that using DI would
be better.
Bernd - 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.
Noel - Again, premature and possibly container dependent.
+0.5 Soren
+0 Norman - like i said no expirences with JNDI
+0.2 Vincenzo
-1 Serge
E2. Use JNDI to lookup users/mail repositories, the store and any other
James component.
-0.5 Stefano
Bernd - 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.
Noel - Again, premature and possibly container dependent.
+0.5 Soren
+0 Norman
+0.2 Vincenzo
-1 Serge
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 Stefano - The API would grow a lot and we'll limit extensibility.
Bernd - 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.
Noel - Probably not. That would require the MailetContext to expand to
understand every possible service, and require every possible service.
But some of them? Perhaps.
-0.9 Soren
-0 Norman
+0.5 Vincenzo - for a proper subset (which one :-) ?)
-0.8 Vincenzo - for everything
-1 Serge
E4. Use Dependency Injection (setter based, constructor based, enabling
interfaces, service locator injection) to automatically satisfy
components dependencies.
+1 Stefano - Imo the right way
+1 Bernd - (but I'm also +1 to _optionally_support_ JNDI)
-? Noel - Where? For the Mailet API? -1. Elsewhere in JAMES? To be
determined.
+0.8 Soren
+0.8 Norman
+0 Vincenzo
+1 Serge - setter or construction based
E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.9 Stefano - Imho this is a bad practice and introduce a "hidden"
dependency.
-0.5 Bernd
-0.8 Soren
-0.5 Norman - Seems to be more a hack..
-0.8 Vincenzo
-1 Serge
------
As you can see we have topics where it seems there is consensus (remove
ServiceManager from the MailetContext and Remove Avalon from "API
Components") and others where we have opposite preferences.
Almost every other question received a bunch of +1 but at least a -1: so
you know this is really a minefield.
That said I really appreciate your effort on this issue: all this text
is just to update you on what happened in the months you were more busy
and what informations I collected about this issue.
Stefano
