james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 02 Mar 2009 20:44:36 GMT

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.


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

View raw message