Robert Burrell Donkin wrote:
On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <[email protected]> wrote:
Robert Burrell Donkin ha scritto:
On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <[email protected]> wrote:
Robert Burrell Donkin ha scritto:
On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <[email protected]> wrote:
I'd kind of worry that if you start using annotations you are going to be
building yet another wiring framework which may not be the ideal focus of
this project.
(unfortunately) i'm not sure a consensus would be possible about
picking a more modern approach
I would prefer the use of an external wiring library instead of writing
our own. JAMES is complex enough to require some complex wiring and
writing our own library is not the right thing to do IMHO.
i see no hope of gaining the consensus required to pick a new container
Why? Did we recently had a poll or did anyone expressed strong opinions
against one or another container? I know I'm less active lately and I
don't remember this.
history
As far as we can go there's no way to ship only container-agnostic
components. One way or another we'll have to use a container and to put
wiring/configuration there and the wiring/configuration is part of the
distribution. We have to choose a container and use its facilities. One
thing we should do is to avoid to put container stuff all around our
code, but we should not write our own container to avoid being
container-specific.
my suggestion is that we develop phoenix to a point where james can
easily be run on other containers. this requires the development of
some james specific wiring and a micro-kernel to plugin into phoenix.
the development of a new container is not necessary.
what I meant is that I prefer to use an existing micro-kernel than
writing our own.
depends how big your micro-kernel is ;-)
the smallest service micro-kernel is a Map
xbean+spring, for example, is not documented, true, but at least it is
used and tested. Something written from scratch would be unused and
undocumented and less bulletproof.
this sounds a good way for the spring deployment to go but i'm not
sure that this would be easy to adapt phoenix to use this approach. if
volunteers step forward who were willing to re-work and maintain the
phoenix container to use a spring-xbeans based micro-kernel that'd be
great by me but i'm not willing to devote the time required.
BTW this is just a preference. If you are convinced that writing your
own stuff is better and you're prepared to write it and make it work,
well, I won't stop you!
i'm proposing a modification to the phoenix container, not creating a
new one. it doesn't need to be bullet proof, just good enough to allow
the james code base to move forward.
Why? I think would should not bother with Phoenix beyond the point of
supporting it as a legacy container. I could be wrong, but no active
committer is willing to support it much longer, so I lean towards ending
support for it after the next release. As an option, we could already
toss it for the upcoming release.
For me, there are a few valid wasy to move forward:
* Switch to Spring completely and only. Right now we have an adapter for
Spring to behave like Phoenix for James components. Removing this
adapter and becoming 'pure Spring' (and retaining all Avalon stuff we
depend on) we would have no Spring specific code within James components.
* Support other prioprietary wiring framworks like Pico/Nanocontainer.
* Use some vendor-independent bean wiring framework like JSR-299 (if I
recall the number correctly, I writing this as I'm offline). Form me, a
precondition for going this route would be that we have a FOOS
BSD-licensed container implementation for it.
I favor the third option.
Bernd
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
