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 Bernd Fondermann <bf...@brainlounge.de> on 2009/03/01 20:33:55 UTC
container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
> IMHO phoenix and the avalon framework are holding the server back
Yes, they do. but not everyone here thinks this way, AFAIU. But maybe
this has changed.
> i would like to be able to run james on the phoenix container but
> don't want the server architecture to be determined by it. my
> preference would be to replace the intrusive Avalon interfaces with
> JSR-250 annotations. this would provide a natural path toward smoother
> integration with JEE containers whilst providing an easy route to
> retain phoenix compatibility. if this sounds like an idea would
> exploring, i'll open a JIRA with more details.
+1.
Maybe worth looking into at ACEU09's hackathon. WDYT?
I'll have a look at the JSR250 spec over the next days to be able to
comment.
Choosing an approach like this makes a lot of sense to me. We don't know
how all this container stuff evolves over the next years - whether it is
Spring or Pico/Nano or OSGi or Phoenix or whatever.
> in the medium term, i think the best approach for james would be a
> blended micro-kernel approach (like service-mix, for example) with a
> top level service locator layer for coursely grained services (with
> internal structure below that assembled by any supported dependency
> injection mechanism).
Maybe, I'd like to think about planning that space trip later. Phoenix
still has too much grativation on James. It's hard enough to eventually
reach a higher orbit to be able too move away and get to the next planet.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> David Jencks wrote:
>>
>> On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>>
>>>> IMHO phoenix and the avalon framework are holding the server back
>>>
>>> Yes, they do. but not everyone here thinks this way, AFAIU. But maybe
>>> this has changed.
>>
>> I found the avalon/pheonix stuff rather hard to understand. IMO if
>> it's kept it would be best as a layer on top of a container-agnostic
>> component layer.
>>>
>>>
>>>> i would like to be able to run james on the phoenix container but
>>>> don't want the server architecture to be determined by it. my
>>>> preference would be to replace the intrusive Avalon interfaces with
>>>> JSR-250 annotations. this would provide a natural path toward smoother
>>>> integration with JEE containers whilst providing an easy route to
>>>> retain phoenix compatibility. if this sounds like an idea would
>>>> exploring, i'll open a JIRA with more details.
>>>
>>> +1.
>>> Maybe worth looking into at ACEU09's hackathon. WDYT?
>>> I'll have a look at the JSR250 spec over the next days to be able to
>>> comment.
>>
>> Also note that something very like spring + osgi is coming to the next
>> osgi spec as rfc 124 blueprint service.
>> Also IIUC JavaEE6 is going to have a much more general dependency
>> injection framework, from what may be currently the web beans spec
>> proposal. I don't know any details on this.
>>
>> Geronimo xbean has a bunch of libraries that make annotation scraping
>> and component creation pretty easy -- xbean-finder and xbean-reflect.
>
> I think that xbean is interesting stuff. I never seriously considered it
> a container for James Server, because I wondered why it is develop
> without a critical amount of public discussion and more than just bare
> documentation. (You know, we have more than enough trouble with a
> certain discontinued container dependency already ;-) ) Hopefully I find
> the time to check again the state the xbean project is in currently.
I share this issue. I looked at xbean 1 year ago and having looked again
today I've been disappointed by this page:
http://geronimo.apache.org/xbean/
Saying the "news" is XBean 2.8 (2007 release) and sharing no
documentation while we know that XBean 3.5 has been released some weeks ago.
Where are the docs? Where are the real news?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Posted by David Blevins <da...@visi.com>.
On Mar 1, 2009, at 4:49 PM, David Jencks wrote:
>
> On Mar 1, 2009, at 1:34 PM, Bernd Fondermann wrote:
>
>> David Jencks wrote:
>>> On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>>>>> IMHO phoenix and the avalon framework are holding the server back
>>>>
>>>> Yes, they do. but not everyone here thinks this way, AFAIU. But
>>>> maybe this has changed.
>>> I found the avalon/pheonix stuff rather hard to understand. IMO
>>> if it's kept it would be best as a layer on top of a container-
>>> agnostic component layer.
>>>>
>>>>
>>>>> i would like to be able to run james on the phoenix container but
>>>>> don't want the server architecture to be determined by it. my
>>>>> preference would be to replace the intrusive Avalon interfaces
>>>>> with
>>>>> JSR-250 annotations. this would provide a natural path toward
>>>>> smoother
>>>>> integration with JEE containers whilst providing an easy route to
>>>>> retain phoenix compatibility. if this sounds like an idea would
>>>>> exploring, i'll open a JIRA with more details.
>>>>
>>>> +1.
>>>> Maybe worth looking into at ACEU09's hackathon. WDYT?
>>>> I'll have a look at the JSR250 spec over the next days to be able
>>>> to comment.
>>> Also note that something very like spring + osgi is coming to the
>>> next osgi spec as rfc 124 blueprint service.
>>> Also IIUC JavaEE6 is going to have a much more general dependency
>>> injection framework, from what may be currently the web beans spec
>>> proposal. I don't know any details on this.
>>> Geronimo xbean has a bunch of libraries that make annotation
>>> scraping and component creation pretty easy -- xbean-finder and
>>> xbean-reflect.
>>
>> I think that xbean is interesting stuff. I never seriously
>> considered it a container for James Server, because I wondered why
>> it is develop without a critical amount of public discussion and
>> more than just bare documentation. (You know, we have more than
>> enough trouble with a certain discontinued container dependency
>> already ;-) ) Hopefully I find the time to check again the state
>> the xbean project is in currently.
>
> xbean is a bunch of closely focussed independent libraries that are
> useful for building containers, it's not a container itself. The
> closest to a container is xbean-spring which is a way to use custom
> schemas adapted to your components with spring.
>
> Xbean libraries are used in at least geronimo, openejb, servicemix,
> and (at least xbean-spring) activemq and apacheds.
>
> As far as discussion, my experience with xbean has pretty much been
> that I look at the code and find that the design is really good and
> often better than the approach I had in my head. After that I don't
> have much to say.
Another way to say it is xbean is a commons-like set of libraries for
common app server things -- constructing an object, finding
annotations, searching the classpath, etc. Each library is a small
tiny island and there is no "whole" that brings them together -- just
a collection of misc reusable bits and pieces.
To add to the list, Struts uses their own copy of xbean-finder, the
annotation scanning stuff. There are really only three classes in
that jar as all the real work is done on the ASM-side, so it's not
such a big deal to just snag a copy of the java files directly.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Posted by David Jencks <da...@yahoo.com>.
On Mar 1, 2009, at 1:34 PM, Bernd Fondermann wrote:
> David Jencks wrote:
>> On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>>>> IMHO phoenix and the avalon framework are holding the server back
>>>
>>> Yes, they do. but not everyone here thinks this way, AFAIU. But
>>> maybe this has changed.
>> I found the avalon/pheonix stuff rather hard to understand. IMO if
>> it's kept it would be best as a layer on top of a container-
>> agnostic component layer.
>>>
>>>
>>>> i would like to be able to run james on the phoenix container but
>>>> don't want the server architecture to be determined by it. my
>>>> preference would be to replace the intrusive Avalon interfaces with
>>>> JSR-250 annotations. this would provide a natural path toward
>>>> smoother
>>>> integration with JEE containers whilst providing an easy route to
>>>> retain phoenix compatibility. if this sounds like an idea would
>>>> exploring, i'll open a JIRA with more details.
>>>
>>> +1.
>>> Maybe worth looking into at ACEU09's hackathon. WDYT?
>>> I'll have a look at the JSR250 spec over the next days to be able
>>> to comment.
>> Also note that something very like spring + osgi is coming to the
>> next osgi spec as rfc 124 blueprint service.
>> Also IIUC JavaEE6 is going to have a much more general dependency
>> injection framework, from what may be currently the web beans spec
>> proposal. I don't know any details on this.
>> Geronimo xbean has a bunch of libraries that make annotation
>> scraping and component creation pretty easy -- xbean-finder and
>> xbean-reflect.
>
> I think that xbean is interesting stuff. I never seriously
> considered it a container for James Server, because I wondered why
> it is develop without a critical amount of public discussion and
> more than just bare documentation. (You know, we have more than
> enough trouble with a certain discontinued container dependency
> already ;-) ) Hopefully I find the time to check again the state the
> xbean project is in currently.
xbean is a bunch of closely focussed independent libraries that are
useful for building containers, it's not a container itself. The
closest to a container is xbean-spring which is a way to use custom
schemas adapted to your components with spring.
Xbean libraries are used in at least geronimo, openejb, servicemix,
and (at least xbean-spring) activemq and apacheds.
As far as discussion, my experience with xbean has pretty much been
that I look at the code and find that the design is really good and
often better than the approach I had in my head. After that I don't
have much to say.
thanks
david jencks
>
>
> Bernd
>
> ---------------------------------------------------------------------
> 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: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Bernd Fondermann <bf...@brainlounge.de>.
David Jencks wrote:
>
> On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>
>>> IMHO phoenix and the avalon framework are holding the server back
>>
>> Yes, they do. but not everyone here thinks this way, AFAIU. But maybe
>> this has changed.
>
> I found the avalon/pheonix stuff rather hard to understand. IMO if it's
> kept it would be best as a layer on top of a container-agnostic
> component layer.
>>
>>
>>> i would like to be able to run james on the phoenix container but
>>> don't want the server architecture to be determined by it. my
>>> preference would be to replace the intrusive Avalon interfaces with
>>> JSR-250 annotations. this would provide a natural path toward smoother
>>> integration with JEE containers whilst providing an easy route to
>>> retain phoenix compatibility. if this sounds like an idea would
>>> exploring, i'll open a JIRA with more details.
>>
>> +1.
>> Maybe worth looking into at ACEU09's hackathon. WDYT?
>> I'll have a look at the JSR250 spec over the next days to be able to
>> comment.
>
> Also note that something very like spring + osgi is coming to the next
> osgi spec as rfc 124 blueprint service.
> Also IIUC JavaEE6 is going to have a much more general dependency
> injection framework, from what may be currently the web beans spec
> proposal. I don't know any details on this.
>
> Geronimo xbean has a bunch of libraries that make annotation scraping
> and component creation pretty easy -- xbean-finder and xbean-reflect.
I think that xbean is interesting stuff. I never seriously considered it
a container for James Server, because I wondered why it is develop
without a critical amount of public discussion and more than just bare
documentation. (You know, we have more than enough trouble with a
certain discontinued container dependency already ;-) ) Hopefully I find
the time to check again the state the xbean project is in currently.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Mar 16, 2009 at 4:41 PM, Eric MacAdie <er...@macadie.net> wrote:
> Robert Burrell Donkin wrote:
>>
>> On 3/12/09, Bernd Fondermann <bf...@brainlounge.de> wrote:
<snip>
>>> 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
>>
>>
>
> I do not like the idea of using JEE. I am running a couple of James servers
> on VPS accounts with 256 MB of memory. Maybe JEE is no longer the memory-hog
> that it used to be, but keeping James as small as possible would be a good
> thing for me.
the JEE option is really about gaining access to a good container
kernel - in a modern JEE container, the weight comes from the plugins.
james would need to ship with just the email plugins.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Eric MacAdie <er...@MacAdie.net>.
Robert Burrell Donkin wrote:
> On 3/12/09, Bernd Fondermann <bf...@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
>
>
I do not like the idea of using JEE. I am running a couple of James
servers on VPS accounts with 256 MB of memory. Maybe JEE is no longer
the memory-hog that it used to be, but keeping James as small as
possible would be a good thing for me.
Eric MacAdie
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 3/12/09, Bernd Fondermann <bf...@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
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Robert Burrell Donkin wrote:
> On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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: 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: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Norman Maurer <no...@apache.org>.
I would prefer to nuke the phonix stuff and just move forward.
I'm not really active atm, so feel free to ignore me ;-)
cheers,
Norman
2009/3/9 Robert Burrell Donkin <ro...@gmail.com>:
> On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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.
>
> - 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
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
>>>> 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
Well, I did it something similar for jSPF:
http://svn.apache.org/repos/asf/james/jspf/trunk/resolver/src/main/java/org/apache/james/jspf/wiring/
But I doubt something similar will be enough for JAMES Server, that's
why I was suggesting that using an existing microkernel could be better
than writing yet another container.
>> 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.
I'm not following you. Unless you plan to put everything in a single
phoenix component you will still have to deal with xinfo and other
phoenix specific stuff even if you write your own kernel.
>> 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.
Understood. I didn't understood you wanted to deal with phoenix code.
I'm not sure I understand why we need to alter the phoenix container and
what it gives us in turn (what's the goal), but if you want to play with
it we'll see the result.
(Using phoenix makes sense only if we leverage its own configuration
stuff, its own kernel and its own JMX stuff. Otherwise let's remove
phoenix and use any other more modern container/framework)
BTW I think I'll better understand your plan once you'll start moving on
it: I'll be here watching :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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.
>> 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.
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.
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!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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
> 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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment
[Re: [jira] Commented: (JAMES-834)...]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> 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.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>
>>> IMHO phoenix and the avalon framework are holding the server back
>>
>> Yes, they do. but not everyone here thinks this way, AFAIU. But maybe this
>> has changed.
>
> I found the avalon/pheonix stuff rather hard to understand. IMO if it's
> kept it would be best as a layer on top of a container-agnostic component
> layer.
+1
>>> i would like to be able to run james on the phoenix container but
>>> don't want the server architecture to be determined by it. my
>>> preference would be to replace the intrusive Avalon interfaces with
>>> JSR-250 annotations. this would provide a natural path toward smoother
>>> integration with JEE containers whilst providing an easy route to
>>> retain phoenix compatibility. if this sounds like an idea would
>>> exploring, i'll open a JIRA with more details.
>>
>> +1.
>> Maybe worth looking into at ACEU09's hackathon. WDYT?
>> I'll have a look at the JSR250 spec over the next days to be able to
>> comment.
>
> Also note that something very like spring + osgi is coming to the next osgi
> spec as rfc 124 blueprint service.
sounds good
> Also IIUC JavaEE6 is going to have a much more general dependency injection
> framework, from what may be currently the web beans spec proposal. I don't
> know any details on this.
>
> Geronimo xbean has a bunch of libraries that make annotation scraping and
> component creation pretty easy -- xbean-finder and xbean-reflect.
cool
> 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
the annotations are the smallest way (i could think of) to remove the
intrusive avalon framework without breaking the phoenix container. i
see them as a stepping stone useful for the phoenix container.
i've outlined the proposal on https://issues.apache.org/jira/browse/JAMES-893
feedback welcomed :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Posted by David Jencks <da...@yahoo.com>.
On Mar 1, 2009, at 11:33 AM, Bernd Fondermann wrote:
>> IMHO phoenix and the avalon framework are holding the server back
>
> Yes, they do. but not everyone here thinks this way, AFAIU. But
> maybe this has changed.
I found the avalon/pheonix stuff rather hard to understand. IMO if
it's kept it would be best as a layer on top of a container-agnostic
component layer.
>
>
>> i would like to be able to run james on the phoenix container but
>> don't want the server architecture to be determined by it. my
>> preference would be to replace the intrusive Avalon interfaces with
>> JSR-250 annotations. this would provide a natural path toward
>> smoother
>> integration with JEE containers whilst providing an easy route to
>> retain phoenix compatibility. if this sounds like an idea would
>> exploring, i'll open a JIRA with more details.
>
> +1.
> Maybe worth looking into at ACEU09's hackathon. WDYT?
> I'll have a look at the JSR250 spec over the next days to be able to
> comment.
Also note that something very like spring + osgi is coming to the next
osgi spec as rfc 124 blueprint service.
Also IIUC JavaEE6 is going to have a much more general dependency
injection framework, from what may be currently the web beans spec
proposal. I don't know any details on this.
Geronimo xbean has a bunch of libraries that make annotation scraping
and component creation pretty easy -- xbean-finder and xbean-reflect.
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.
>
>
> Choosing an approach like this makes a lot of sense to me. We don't
> know how all this container stuff evolves over the next years -
> whether it is Spring or Pico/Nano or OSGi or Phoenix or whatever.
>
>> in the medium term, i think the best approach for james would be a
>> blended micro-kernel approach (like service-mix, for example) with a
>> top level service locator layer for coursely grained services (with
>> internal structure below that assembled by any supported dependency
>> injection mechanism).
>
> Maybe, I'd like to think about planning that space trip later.
> Phoenix still has too much grativation on James. It's hard enough to
> eventually reach a higher orbit to be able too move away and get to
> the next planet.
Seems like a good long term goal to me.
thanks
david jencks
>
>
> Bernd
>
> ---------------------------------------------------------------------
> 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: container and component model [Re: libs in spring deployment [Re:
[jira] Commented: (JAMES-834)...]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 1, 2009 at 7:33 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> IMHO phoenix and the avalon framework are holding the server back
>
> Yes, they do. but not everyone here thinks this way, AFAIU. But maybe this
> has changed.
>> i would like to be able to run james on the phoenix container but
>> don't want the server architecture to be determined by it. my
>> preference would be to replace the intrusive Avalon interfaces with
>> JSR-250 annotations. this would provide a natural path toward smoother
>> integration with JEE containers whilst providing an easy route to
>> retain phoenix compatibility. if this sounds like an idea would
>> exploring, i'll open a JIRA with more details.
>
> +1.
> Maybe worth looking into at ACEU09's hackathon. WDYT?
+1
i'm very keen to look Mailet 3 as well, especially focussing on
general MIME documents so that micro-messaging and blogging can be
added into the mix and processed by mailets
but i think that annotations are the best approach for both mailets and james
> I'll have a look at the JSR250 spec over the next days to be able to
> comment.
cool - the good news is that it's small :-)
> Choosing an approach like this makes a lot of sense to me. We don't know how
> all this container stuff evolves over the next years - whether it is Spring
> or Pico/Nano or OSGi or Phoenix or whatever.
+1
>> in the medium term, i think the best approach for james would be a
>> blended micro-kernel approach (like service-mix, for example) with a
>> top level service locator layer for coursely grained services (with
>> internal structure below that assembled by any supported dependency
>> injection mechanism).
>
> Maybe, I'd like to think about planning that space trip later. Phoenix still
> has too much grativation on James. It's hard enough to eventually reach a
> higher orbit to be able too move away and get to the next planet.
:-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org