james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Sun, 15 Mar 2009 11:53:16 GMT
On 3/12/09, Bernd Fondermann <bf_jak@brainlounge.de> wrote:
> Robert Burrell Donkin wrote:

<snip>

>> 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?

Short version:
I'm not interested in wasting any more energy tooling for Phoenix

Long version:

1 It's a dead container
1A functions stop working in new JVMs
1B developers don't want to learn avalon or phoenix
1C bugs don't get fixed
1D tooling isn't available for third party libraries
2 Avalon-Phoenix isn't good enough
2A Assembly requires poor design choices to be baked in
2B Service Location requires strong coupling to Avalon and adoption of
a particular architectural approach
2C too much work is required to assemble services composed from finely
grained components
2D service location requires too much effort and requires changes to
the configuration document which we are then required to support going
forward

> I think would should not bother with Phoenix beyond the point of
> supporting it as a legacy container.

The cost of supporting Phoenix (in it's current form) is IMO too high
to continue unless volunteers interested in investing the time
required step up

Anyone interested?

> 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.

I think it's better to think about separate concerns

The annotations really only address service location not service
assembly. Spring is IMO a much better option for service assembly than
the variety of hand crafted alternative used ATM by James but IMO this
choice can be left to components.

Service location can also be done by Spring but there are credible
alternatives here. JEE or OSGi offer interesting possibilities. For
example, Service Mix has a very cool kernel which blends Spring and
OSGi. Then again, Felix and Geronimo are both have significant
advantages. It would probably be best just to pick one container but
IMHO developers would need to step up to help.

Volunteers?

Robert

>
>    Bernd
>
>
>
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message