You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/07/13 16:48:33 UTC
[VOTE] Wiring/Dependencies/Lifecycle Management for next James
Hi all,
This is a test, I hope it will work because I don't see another simple
solution to move forward from the current stall.
I'm starting this vote because I saw that there is a lot moving around
this issue and we probably currently don't share a common idea, so it's
better to see what the preferences/likes/dislikes/vetoes are in the
various aspects of this issue.
I expect to receive clear -1...+1 votes (decimal values allowed) even if
this is not a "standard" vote. I'd like to keep discussion out from this
thread in order to keep this clean (there are a lot of options, so it's
better to keep it clean).
I think that a small sentence explaing the vote should be allowed, but
please *small* or this will become a mess (maybe you want to add
priorities and dependencies on other votes).
The votes are many and are not clearly organized, but I hope this will
give us a first overview on the things where we have agreements and
things that may be discussed more. We have a broad range of
possibilities for our architecture, so we should try to narrow the real
options that will not be vetoed and get more consensus.
I want to see if there is at least one option that will not be vetoed by
someone :-/
This is far from complete, but I saw that we was not reaching an
agreement, so we need to understand what is the current position of each
committer before starting working on things that will be vetoed.
I hope that after this one it will be more clean what are the liked
scenarios and that we can start with small proposals for solutions,
roadmap and specific votes.
I will put my votes in a reply to this.
Here is a glossary:
"API Components" => Matcher/Mailets/"new CommandHandlers"
"Top Level Components" => The components currently wired in assembly.xml
"Other James Components" => Other components instantiated by Top Level
Components but not directly handled by Phoenix.
"Phoenix" => Our current Avalon container
"Avalon" => The avalon framework
"Cornerstone" => I will consider both Cornerstone and Excalibur
components inside this name
Example votes:
"+1" => I really like this and I will put my hands in for this to happen
"+0.1 .. +0.9" => I like this solution
"+0" => I'm not against this
"-0" => I can live with it, but I prefer something else.
"-0.1 .. -0.9" => I don't like it, but I will not veto it
"-1" => I'm probably going to veto this
And now the bulk questions:
A. Deprecate phoenix
A1. Replace it with Plexus (http://plexus.codehaus.org/)
A2. Replace it with another Avalon compliant container (name it)
A3. Replace it with Felix (http://incubator.apache.org/felix/)
B. Remove avalon
B1. Remove it from "API Components"
B2. Remove it from both API Components and Other James Components
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
C. Remove Cornerstone
C1. Remove cornerstone dependencies in favor of Jakarta commons
libraries where available
C2. Use MINA to replace sockets/connection dependencies
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
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)
D2. Keep Avalon interfaces but write our own mini container for non Top
Level Components.
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)
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
E2. Use JNDI to lookup users/mail repositories, the store and any other
James component.
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)
E4. Use Dependency Injection (setter based, constructor based, enabling
interfaces, service locator injection) to automatically satisfy
components dependencies.
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
G1. Use CDI (constructor base DI)
G2. Use Setters
G3. Use Setters with Enabling Interfaces
G4. Keep single setter for ServiceLocator (ala Avalon)
G5. Use reflection and convention over configurations for the above DI
Furthermore these technologies could be used to sole one or more aspects
of the above points, please give your opinions.
H1. Use Spring
H2. Use XBean
H3. Use OSGi Declarative Services
Stefano
PS: I'm willing to track this thread and produce an (i hope unbiased)
overview of the result.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Danny Angus <da...@gmail.com>.
On 21/07/06, Stefano Bagnara <ap...@bago.org> wrote:
> I think it worked, I will try to use this kind of messages in future,
> and I'll use the POLL identifier so everyone will be happy.
Cool, I think it worked too. [VOTE] has a special meaning, [VOTES]
record concrete decisions we've made, using [POLL] is a good idea.
> If I opened 10 threads with a single discussion about each topic I bet I
> wouldn't have received so much answers and I now we only would have
> random threads with unfisnished discussions and nothing more.
This is much less important for a POLL than a VOTE, I'm sure you can
see that I thought this was a VOTE and was too much for a single
issue.
> If james committer was faster in votes we could easily use a different
> approach. This "poll" is a custom solution that I decided to experiment
> because of lacks in the current way we were working.
I think plenty of other projects use this approach, this is an OK
thing to do. However don't confuse the results of the poll with a
mandate to put the items into practice, it is an indication that we
comfortable with the proposals but authority would only come with a
VOTE. But as we practice Commit Then Review you have achieved enough
to make the progress you're after.
Nice work,
d.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> On 13/07/06, Stefano Bagnara <ap...@bago.org> wrote:
>
>> I'd like to keep discussion out from this
>> thread in order to keep this clean (there are a lot of options, so it's
>> better to keep it clean).
>
> Perhaps it would be better to start with a [PROPOSAL] which can be
> discussed.
> Perhaps also it might help to break a big proposal into several smaller
> ones.
This is NOT a proposal. The best definition is a "vote-like" Poll.
This has not official value like a real VOTE, but I hope we all are
serious enough to answer the truth.
I think it worked, I will try to use this kind of messages in future,
and I'll use the POLL identifier so everyone will be happy.
If I opened 10 threads with a single discussion about each topic I bet I
wouldn't have received so much answers and I now we only would have
random threads with unfisnished discussions and nothing more.
Now that already 9 committers voted I think this was the best approach
to the current problem.
I think that we now have something more to start specific proposal or
specific discussions.
As an example we all voted + to introduce MINA, as another example I
only from this answers understood that we have more consensus on use of
SDI without Enabling interfaces and without autowiring.
Without this poll I would have started working on a proposal including
autowiring.. This received -1 in this poll, I will not loose time in this.
If james committer was faster in votes we could easily use a different
approach. This "poll" is a custom solution that I decided to experiment
because of lacks in the current way we were working.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Danny Angus <da...@gmail.com>.
On 13/07/06, Stefano Bagnara <ap...@bago.org> wrote:
> I'd like to keep discussion out from this
> thread in order to keep this clean (there are a lot of options, so it's
> better to keep it clean).
Perhaps it would be better to start with a [PROPOSAL] which can be discussed.
Perhaps also it might help to break a big proposal into several smaller ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Danny Angus <da...@gmail.com>.
On 13/07/06, Stefano Bagnara <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
> And now the bulk questions:
>
> A. Deprecate phoenix
+0.8
> 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.2
>
> B. Remove avalon
+0.8
> B1. Remove it from "API Components"
+0.8
> B2. Remove it from both API Components and Other James Components
+0.8
> B3. Remove it from all the codes and keep wrapper for Top Level
> Components to be adapted to the container (Avalon or other).
+0.8
>
> C. Remove Cornerstone
+0.8
> C1. Remove cornerstone dependencies in favor of Jakarta commons
> libraries where available
+0.8
> C2. Use MINA to replace sockets/connection dependencies
+0.8
> C3. Import code from not replaceable libraries to James codebase
> (refactoring it to remove Avalon and anything else needed)
+0.8
>
> 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.8
> 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
>
> E. Specific API Components issues:
> E1. Use JNDI to lookup datasources
+0.2
> E2. Use JNDI to lookup users/mail repositories, the store and any
> other James component.
+0.2
> 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.5 for a proper subset (which one :-) ?)
-0.8 for everything
> E4. Use Dependency Injection (setter based, constructor based,
> enabling interfaces, service locator injection) to automatically
> satisfy components dependencies.
+0
> E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.8
>
> If you voted +X to something DI related please also vote this:
>
> G. Dependency Injection
+0
> G1. Use CDI (constructor base DI)
> G2. Use Setters
> G3. Use Setters with Enabling Interfaces
> G4. Keep single setter for ServiceLocator (ala Avalon)
> G5. Use reflection and convention over configurations for the above DI
>
> Furthermore these technologies could be used to sole one or more
> aspects of the above points, please give your opinions.
> H1. Use Spring
+0
> H2. Use XBean
+0
> H3. Use OSGi Declarative Services
+0
Vincenzo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> On 7/13/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Hi all,
>>
>> This is a test, I hope it will work because I don't see another simple
>> solution to move forward from the current stall.
>
> It's a vote, not a test, isn't it? ;-)
It is a test because it is not an "official" apache vote: there is not
this concept of a set of votes and I redefined the possible answers and
so on.
I'm thinking to start votes about various things since I stopped working
on trunk, but I have not found clear simple votes that would solve the
main problem (maybe I am the only one feeling a problem).
"This is a test", because I really don't know if the result will help or
not. I saw that standard discussions often do not bring us to a clear
objective/roadmap and to understand what is good to do and what is not
good. I hope that using simple numbers will help us.
Even if this is not an official vote I expect people to vote like an
official votes. I don't think that would be helpful if people vote +1
here and then -1 on the real vote made later on the specific issue.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Bernd Fondermann <be...@googlemail.com>.
On 7/13/06, Stefano Bagnara <ap...@bago.org> wrote:
> Hi all,
>
> This is a test, I hope it will work because I don't see another simple
> solution to move forward from the current stall.
It's a vote, not a test, isn't it? ;-)
> I'm starting this vote because I saw that there is a lot moving around
> this issue and we probably currently don't share a common idea, so it's
> better to see what the preferences/likes/dislikes/vetoes are in the
> various aspects of this issue.
+1
> The votes are many and are not clearly organized, but I hope this will
> give us a first overview on the things where we have agreements and
> things that may be discussed more. We have a broad range of
> possibilities for our architecture, so we should try to narrow the real
> options that will not be vetoed and get more consensus.
Maybe it would have been better to split this up into a voting-cascade
instead of trying to catch it all in one vote. But here we go...
> And now the bulk questions:
>
> A. Deprecate phoenix
> A1. Replace it with Plexus (http://plexus.codehaus.org/)
> A2. Replace it with another Avalon compliant container (name it)
> A3. Replace it with Felix (http://incubator.apache.org/felix/)
+0 to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
> B. Remove avalon
> 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
> 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
> C2. Use MINA to replace sockets/connection dependencies
> C3. Import code from not replaceable libraries to James codebase
> (refactoring it to remove Avalon and anything else needed)
+1 C1-C3, but I consider this to be a very long time project, curretly
more of the visionary type. I have many sympathies for starting with
MINA soon.
> 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)
+0 (I see my proposal only as an intermediate step on the way to
reduce Avalon deps)
D4-BF. Use some simple, lightweight form of (auto-)wiring, there must
be something out there (if not XBeans)
+1
> E. Specific API Components issues:
> E1. Use JNDI to lookup datasources
> E2. Use JNDI to lookup users/mail repositories, the store and any other
> James component.
> 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)
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.
> E4. Use Dependency Injection (setter based, constructor based, enabling
> interfaces, service locator injection) to automatically satisfy
> components dependencies.
+1 (but I'm also +1 to _optionally_support_ JNDI)
> E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.5
> G. Dependency Injection
> G1. Use CDI (constructor base DI)
> G2. Use Setters
> G3. Use Setters with Enabling Interfaces
+1 G1-G3, I am not enough a religious DI fanatic to exclude any of those
> G4. Keep single setter for ServiceLocator (ala Avalon)
-0 all other options are superior
> G5. Use reflection and convention over configurations for the above DI
+0,5
>
> Furthermore these technologies could be used to sole one or more aspects
> of the above points, please give your opinions.
> H1. Use Spring
> H2. Use XBean
> H3. Use OSGi Declarative Services
+1 H1-H3 (sigh, if we only where _that_ far already, I'd take any of these :-) )
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[POLL RESULT] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
Here is a summary of casted opinions.
Please note that I tried to resemble votes as -?/+? when there was a too
long description without a vote.
At a first glance I can say that we have found consensus on fewer issue
than I expected.
----------------
We all voted +? to this:
B1. Remove Avalon from API Components.
C. Remove Cornerstone
C1. Remove Cornerstone dependencies in favor of Jakarta Commons when
available
C2. Use MINA to *add* sockets/connection dependencies (Noel is against
the replace)
G2. Use Setters (as the preferred DI solution)
We all voted against this:
E5. Keep the ServiceManager as a property stored in the MailetContext.
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) [Note that Vincenzo is +0.5 on adding a
subset of this services]
About the container we all have no strong opinions: no vote under -0 has
been casted to A* questions.
The main problem is that about E5 and B1 we agreed on the goal but we
have very different views on how to do that. If we take the -1 as vetoes
then we have currently *no* accepted solution.
Here is a list of things where no votes under "-0" have been casted and
there is at least a "+1":
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
H3. Use OSGi Declarative Services
The remaining issues have contrasting answers (-1 .. +1).
I think that the experiment worked, and that this is a "better than
nothing" starting point to start specific discussions or specific
proposals having an overview of the mood of the team about each aspect.
Stefano
And here is the summary:
--------------
A. Deprecate phoenix
-0 Stefano (in the short term (an year))
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
+1 Noel - But in what timeframe? I am in no rush
+0.8 Søren - I do not like that we are based so heavily on unmaintained
codebase. If we keep these we should make them part of the James codebase.
+0.8 Vincenzo
-1 Serge - See the comment in the message
A1. Replace it with Plexus (http://plexus.codehaus.org/)
+0 Stefano (Plexus seems to be actively developed (for maven2) and
supports avalon components and more (must be investigated))
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
-? Noel - 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
-0 Soren
+0 Norman - Never used..
-0 Vincenzo
-0 Serge
A2. Replace it with another Avalon compliant container (name it)
-0 Stefano (After excluding Loom and having upgraded to the latest
Phoenix I don't see other plausible containers).
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
-? Noel - 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
-0 Soren
-0 Norman
-0 Vincenzo
-0 Serge
A3. Replace it with Felix (http://incubator.apache.org/felix/)
-0 Stefano (in the short term because OSGi will increase the time to
become confortable with the application. +0.5 in the long term)
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
+? Noel - 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
+0.2 Soren
+0.5 Norman - Felix seems to be very intressting.. But maybe its a bit
overkill..
+0.2 Vincenzo
-0 Serge
B. Remove avalon
-0 Stefano - I feel good with Avalon, imho we can remove some of its
pattern (ServiceManager) and keep the basic interfaces.
+1 Bernd
+1 Noel - But again, there is a migration strategy
+0.8 Soren
+0.8 Vincenzo
+1 Serge - (ideal world)
B1. Remove it 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
B2. Remove it from both API Components and Other James Components
-0.5 Stefano - nonsense: I prefer B1 or B3.
+1 Bernd
+0.5 Soren
-0.5 Norman
+0.8 Vincenzo
+1 Serge
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
-0 Stefano
+1 Bernd
+? Noel - *EVENTUALLY*
+0.5 Soren
-0.5 Norman
+0.8 Vincenzo
+1 Serge
C. Remove Cornerstone
+0.2 Stefano - but I will vote each change library per library.
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+? Noel - Again, a process, not a cliff.
+0.8 Soren
+0.8 Vincenzo
+1 Serge
C1. Remove cornerstone dependencies in favor of Jakarta commons
libraries where available
+0.5 Stefano
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+1 Noel
+0.8 Soren
+0.5 Norman
+0.8 Vincenzo
+1 Serge
C2. Use MINA to replace sockets/connection dependencies
+1 Stefano - 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)
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
-1 Noel - to replace.
+1 Noel - to ADD new MINA versions that will EVENTUALLY replace the
current ones. Solution to this problem already outlined.
+0.8 Soren
+1 Norman - After what i see on apacheCon this seems to be the best way
to get a better rid of many connections etc.
+0.8 Vincenzo
+0 Serge
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
-0 Stefano - I would do this only for Excalibur components (Avalon
specific) if we decide to remove Avalon from everywhere.
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+? Noel - If necessary. What do you have in mind that is not replaceable?
+0.8 Soren
-0 Norman
+0.8 Vincenzo
-0 Serge
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 Stefano
-0 Bernd
+? Noel - 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.
-0 Soren
+0 Norman - Can say anything about this.. no expirence
+0 Vincenzo
-1 Serge
D2. Keep Avalon interfaces but write our own mini container for non Top
Level Components.
+1 Stefano - 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).
-0 Bernd
-1 Noel - -1 as a policy, not code.
-0 Soren
+0.5 Norman - I like avalon ;-)
-0.8 Vincenzo
-1 Serge
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 Stefano - If they have to be identical to Avalon interfaces I'd
keep Avalon ones.
+0 Bernd - (I see my proposal only as an intermediate step on the way to
reduce Avalon deps)
+? Noel - 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.
-0.5 Soren
+0.8 Norman - I like Bernds idea..
+0.2 Vincenzo
-1 Serge
D4. Use some simple, lightweight form of (auto-)wiring, there must
(added by Bernd, not voted) be something out there (if not XBeans)
+1 Bernd
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
If you voted +X to something DI related please also vote this:
G. Dependency Injection
Noel made a long comment to this. read it in its message. (-? to DI for
Datasources)
+0 Vincenzo
G1. Use CDI (constructor base DI)
-0 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
-0 Soren
+0 Norman
+0 Vincenzo
+0.5 Serge
G2. Use Setters
+0.8 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
+0.5 Soren
+0.5 Norman
+0 Vincenzo
+1 Serge
G3. Use Setters with Enabling Interfaces
+1 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
+0.5 Soren
+0.5 Norman
+0 Vincenzo
-1 Serge
G4. Keep single setter for ServiceLocator (ala Avalon)
-0 Stefano
-0 Bernd - all other options are superior
-0.8 Soren
+0 Norman
+0 Vincenzo
-1 Serge
G5. Use reflection and convention over configurations for the above DI
+1 Stefano (even if we may need to add configurability for advanced setups)
+0,5 Bernd
+0.5 Soren
+0 Norman
+0 Vincenzo
-1 Serge
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 Stefano Not avalon friendly, too much xml configuration, big
dependency.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
-1 Noel
+0.5 Soren (I really like Spring)
-0 Norman
+0 Vincenzo
+1 Serge
H2. Use XBean
-0.5 Stefano - I'd like to see what path is followed by Geronimo and
Directory in this aspect. I would not be an early user.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
Noel - Premature. And where?
+0 Soren
+0 Norman
+0 Vincenzo
+0 Serge
H3. Use OSGi Declarative Services
-0 Stefano - 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.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
+? Noel - This is my preferred direction. But does that mean that
Mailets should be OSGi components? No.
-0 Soren
+0.5 Norman
+0 Vincenzo
-0 Serge
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Søren Hilmer <sh...@widetrail.dk>.
Hi,
Must say that I feel a little uncomfortable with this vote, as many of the
issues IMO needs more discussion/investigation before calling a vote, but I
will play along and vote.
Also there are issues I rather saw moving like: getting rid of JavaMail :-)
On Thursday 13 July 2006 16:48, Stefano Bagnara wrote:
>
> And now the bulk questions:
>
> A. Deprecate phoenix
+0.8 I do not like that we are based so heavily on unmaintained codebase. If
we keep these we should make them part of the James codebase.
> 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.2
>
> B. Remove avalon
+0.8
> B1. Remove it from "API Components"
+0.8
> B2. Remove it from both API Components and Other James Components
+0.5
> B3. Remove it from all the codes and keep wrapper for Top Level
> Components to be adapted to the container (Avalon or other).
+0.5
>
> C. Remove Cornerstone
+0.8
> C1. Remove cornerstone dependencies in favor of Jakarta commons
> libraries where available
+0.8
> C2. Use MINA to replace sockets/connection dependencies
+0.8
> C3. Import code from not replaceable libraries to James codebase
> (refactoring it to remove Avalon and anything else needed)
+0.8
>
> 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)
-0.5
>
> E. Specific API Components issues:
> E1. Use JNDI to lookup datasources
+0.5
> 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.9
> E4. Use Dependency Injection (setter based, constructor based, enabling
> interfaces, service locator injection) to automatically satisfy
> components dependencies.
+0.8
> E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.8
>
> 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.5
> G3. Use Setters with Enabling Interfaces
+0.5
> G4. Keep single setter for ServiceLocator (ala Avalon)
-0.8
> G5. Use reflection and convention over configurations for the above DI
+0.5
>
> 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 (I really like Spring)
> H2. Use XBean
+0
> H3. Use OSGi Declarative Services
-0
--Søren
>
>
> Stefano
>
> PS: I'm willing to track this thread and produce an (i hope unbiased)
> overview of the result.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't see another simple solution to move forward from the current
stall.
What stall? We're certainly not going to design an API by voting first and
working second.
Meantime, we are making very fine progress on the protocol handler
revisions, which should clear the way to relatively easy support for both
socket-based and NIO-based handlers. And we should be able to easily
integrated jSPF, too.
Since we cannot use InetAddress even with dnsjava plugged in as the
provider, I plan to commit samples to show how we can easily replace those
calls with JNDI. I certainly do not expect to use that for the critical and
specific DNS work required by RemoteDelivery, but for other uses, we can do
it, e.g., in the DNSRBL code:
dnsCtx.getAttributes(host, new String[] { "A", "TXT" })
which get both A and TXT records from the DNS, which is something that
InetAddress cannot do anyway, so unless we want to mandate the dnsjava API
as part of the Mailet API, JNDI handles it quite nicely and easily.
As for RemoteDelivery, we might decide to remove the SMTP locator method
from the MailetContext, and provide a discoverable service that implements
the interface. Again, the concept being to not burden all Mailet Containers
with things that they don't need to implement.
Is there something specific you have in mind that you would like to see move
forward at this time?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Stefano Bagnara wrote:
> Bernd Fondermann wrote:
>> Nevertheless, I think the thread you started serves a purpose by
>> collecting a "mood board" on some/most of the pending discussions.
>> And it certainly should not be intended as a way to shut down
>> discussions.
>
>
> I really hope this will stop religious threads that do not bring
> anywhere. I hope that starting from the results of this "poll" (do we
> want to call it poll?) we can have something more concrete to discuss
> about.
Let's call it poll :-) .
>
> I asked to not start discussions inside the vote replies because I
> wanted to be able to collect the results in an easy way. Imho
> discussions will belong to the result comment thread.
>
Correct.
>> Most of the topics are such long-termed endevours that it is
>> impossible to do a "bulk commit" now.
>
>
> I agree, I never thought about a bulk commit.
> Btw I think that we did a lot of discussions that are meaningless if
> not contextualized in a long term goal or at least in a set of
> roadmaps we could reach consensus upon.
Correct.
>
>> What I agree on with you and I feel you are missing is the free way
>> to keep development going. I'd recommend to take one piece at a time
>> from the pile of todo's, recall or start some dev-discussions, then
>> vote, then implement and be flexible enough to accept peoples ongoing
>> input.
>
>
> Do you think I should have better started a single vote for each
> question?
> I thought at solution for weeks.. unfortunately this my best shot
> now... if anyone has better way to bring our trunk to life and
> increase probability to have a James 3.0 in a real future I would
> really be happy to use my time to partecipate.
>
>>> I explained what the various -1..+1 votes should be used for.
>>> That said, you should now explain your reply in the context of the
>>> topic I started.
>>>
>> <snip/>
>>
>>>
>>> Btw I hope you will be more flexible about this discussion
>>> procedures the next times.
>>
>>
>> Noel (whom you are responding to) like everyone else participating in
>> the project has the right and the duty to define "procedures". He
>> responded in a very flexible way, I think.
>
>
> I only wanted to say that I opened a topic, I asked to reply with
> decimal votes, he decided to change the rule. Imo this is not good:
> other committers did understand my proposed way to vote.
> I just asked flexibility about this. In the context of my vote/poll
> each of the -1 by Noel is a VETO... you know, if everyone put so much
> vetoes in a list we'll never reach consensus.
>
I understood and agree with your approach. Just remember that not
everyone has enough knowledge/convincement/clear thoughts on every topic
(and this is why I answered with several "+0" :-) ).
>>> I stopped my activity on the james trunk because I feel out of synch
>>> with the team, I'm simply trying to understand if there is still
>>> space for my work or not.
>>
>>
>> I'm very confident, there is. But having people with different
>> opinions is not a burden, it's a gift. The community is growing, so
>> there are popping up more opinions, what do you expect? (with
>> community growing linear, opinions are growing exponentially ;-))
>>
>> Bernd
>
>
> It's all about consensus: I'm not trying to convince anyone of
> anything, I'm collecting personal positions, to be able to understand
> where is the space for consensus.
>
> I feel I am the one that much more try to understand other opinions
> and try to find consensus.
>
> As an example you can read our last threads about configurations: I
> tried to put out a list of possibilities, I declared my preferences, I
> examinated proposals by other members, I made questions... thread died.
I agree with Bernd. In any case, sometimes ideas have to die and
resuscitate again to succeed, as they may be felt less mature or
realistic at the beginning (looks like I'm too much a philosopher now,
or a priest ;-) ).
>
> I know I'm hard in words, but 1) I never learned soft words in english
> 2) I'm just trying to be concrete. James needs much more concrete things.
Words in foreign languages can be subtly misunderstood (think at the
recent Zidane vs. Materazzi "thread" ;-) ). Let's remember that and
*never* feel offended.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> I think I really well explained what was the goal of the "vote" and
>> made clear this is not a standard vote but a "vote-like". I used the
>> [VOTE] subject to attract replies.
>
> To attract replies, you shouldn't use [VOTE], if you don't call for a
> vote. Please take people seriously.
I really hope you don't think I don't take people seriously.
I used VOTE because this is like a VOTE but ASF never defined this kind
of vote, so I thought it was better to try this test (we are a
community, we should try to find solutions even without a lawyer) with
multiple vote-like questions as a way to collect as much as possible an
overview of our ideas.
Maybe I'm the only one confused but I see that is happened too much that
we thought we were in line with a goal while we were working on things
that have been vetoed (or criticized) when done.
> Nevertheless, I think the thread you started serves a purpose by
> collecting a "mood board" on some/most of the pending discussions. And
> it certainly should not be intended as a way to shut down discussions.
I really hope this will stop religious threads that do not bring
anywhere. I hope that starting from the results of this "poll" (do we
want to call it poll?) we can have something more concrete to discuss about.
I asked to not start discussions inside the vote replies because I
wanted to be able to collect the results in an easy way. Imho
discussions will belong to the result comment thread.
> Most of the topics are such long-termed endevours that it is impossible
> to do a "bulk commit" now.
I agree, I never thought about a bulk commit.
Btw I think that we did a lot of discussions that are meaningless if not
contextualized in a long term goal or at least in a set of roadmaps we
could reach consensus upon.
> What I agree on with you and I feel you are missing is the free way to
> keep development going. I'd recommend to take one piece at a time from
> the pile of todo's, recall or start some dev-discussions, then vote,
> then implement and be flexible enough to accept peoples ongoing input.
Do you think I should have better started a single vote for each question?
I thought at solution for weeks.. unfortunately this my best shot now...
if anyone has better way to bring our trunk to life and increase
probability to have a James 3.0 in a real future I would really be happy
to use my time to partecipate.
>> I explained what the various -1..+1 votes should be used for.
>> That said, you should now explain your reply in the context of the
>> topic I started.
>>
> <snip/>
>>
>> Btw I hope you will be more flexible about this discussion procedures
>> the next times.
>
> Noel (whom you are responding to) like everyone else participating in
> the project has the right and the duty to define "procedures". He
> responded in a very flexible way, I think.
I only wanted to say that I opened a topic, I asked to reply with
decimal votes, he decided to change the rule. Imo this is not good:
other committers did understand my proposed way to vote.
I just asked flexibility about this. In the context of my vote/poll each
of the -1 by Noel is a VETO... you know, if everyone put so much vetoes
in a list we'll never reach consensus.
>> I stopped my activity on the james trunk because I feel out of synch
>> with the team, I'm simply trying to understand if there is still space
>> for my work or not.
>
> I'm very confident, there is. But having people with different opinions
> is not a burden, it's a gift. The community is growing, so there are
> popping up more opinions, what do you expect? (with community growing
> linear, opinions are growing exponentially ;-))
>
> Bernd
It's all about consensus: I'm not trying to convince anyone of anything,
I'm collecting personal positions, to be able to understand where is the
space for consensus.
I feel I am the one that much more try to understand other opinions and
try to find consensus.
As an example you can read our last threads about configurations: I
tried to put out a list of possibilities, I declared my preferences, I
examinated proposals by other members, I made questions... thread died.
I know I'm hard in words, but 1) I never learned soft words in english
2) I'm just trying to be concrete. James needs much more concrete things.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
>
>> 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.
>
>
> I think I really well explained what was the goal of the "vote" and made
> clear this is not a standard vote but a "vote-like". I used the [VOTE]
> subject to attract replies.
To attract replies, you shouldn't use [VOTE], if you don't call for a
vote. Please take people seriously.
Nevertheless, I think the thread you started serves a purpose by
collecting a "mood board" on some/most of the pending discussions. And
it certainly should not be intended as a way to shut down discussions.
Most of the topics are such long-termed endevours that it is impossible
to do a "bulk commit" now.
What I agree on with you and I feel you are missing is the free way to
keep development going. I'd recommend to take one piece at a time from
the pile of todo's, recall or start some dev-discussions, then vote,
then implement and be flexible enough to accept peoples ongoing input.
> I explained what the various -1..+1 votes should be used for.
> That said, you should now explain your reply in the context of the topic
> I started.
>
<snip/>
>
> Btw I hope you will be more flexible about this discussion procedures
> the next times.
Noel (whom you are responding to) like everyone else participating in
the project has the right and the duty to define "procedures". He
responded in a very flexible way, I think.
> I stopped my activity on the james trunk because I feel out of synch
> with the team, I'm simply trying to understand if there is still space
> for my work or not.
I'm very confident, there is. But having people with different opinions
is not a burden, it's a gift. The community is growing, so there are
popping up more opinions, what do you expect? (with community growing
linear, opinions are growing exponentially ;-))
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> 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.
I think I really well explained what was the goal of the "vote" and made
clear this is not a standard vote but a "vote-like". I used the [VOTE]
subject to attract replies.
I explained what the various -1..+1 votes should be used for.
That said, you should now explain your reply in the context of the topic
I started.
I hope that in future threads similar to this you will accept to
understand my proposed rules: When I wrote the glossary and the vote I
expected I thought at them.
About Apache votes I read here:
http://www.apache.org/foundation/voting.html
That apart from votes on proposal about code modifications (that are +1,
-1) the standard votes are in the *range* -1..+1
Here is the snippet:
-----
Expressing Votes: +1, 0, -1, and Fractions
The voting process in Apache may seem more than a little weird if you've
never encountered it before. Votes are represented as numbers between -1
and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'
The in-between values are indicative of how strongly the voting
individual feels. Here are some examples of fractional votes and ways in
which they might be intended and interpreted:
* +0: 'I don't feel strongly about it, but I'm okey with this.'
* -0: 'I won't get in the way, but I'd rather we didn't do this.'
* -0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
* ++1: 'Wow! I like this! Let's do it!'
* -0.9: 'I really don't like this, but I'm not going to stand in the way
if everyone else wants to go ahead with it.'
* +0.9: 'This is a cool idea and i like it, but I don't have time/the
skills necessary to help out.'
------------
Btw I hope you will be more flexible about this discussion procedures
the next times.
I'm trying to understand if there is at least one common shared goal
where we can join our forces.
I stopped my activity on the james trunk because I feel out of synch
with the team, I'm simply trying to understand if there is still space
for my work or not.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org