geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Consolidating the community
Date Mon, 31 Oct 2005 18:17:07 GMT
Hi John,

I don't want to loose focus on the core consolidation discussion, but  
since you asked and I love talking about XBean so much :D

For those of you that don't know what XBean (formally know as GBean),  
it is a extensible server framework for POJOs.  The goal of this  
project is to created a plugin based server analogous to Eclipse  
being a plugin based IDE.  Using the Maven repo we will be able to  
discover and download server plugins, and using OSGi (the plugin  
system eclipse uses) we will load them in to the server.  In addition  
to this, XBean will support several configuration and  
componentization models including Spring, Geronimo GBeans, and via an  
integration with Plexus we will also support Maven, Continuum,  
Plexus, Avalon and Pico components and configurations.

On Oct 30, 2005, at 7:30 PM, Hiram Chirino wrote:

> On Oct 29, 2005, at 11:54 PM, John Sisson wrote:
>
>> Sounds like a great idea.
>>
>> OpenEJB, TranQL, ActiveMQ would be great to have as part of the  
>> community.
>>
>> I noticed that Xbean was suggested.  How is Xbean currently  
>> related to Geronimo?  Is this the Spring based gbean.org project  
>> with a new name (www.gbean.org now takes me to the Codehaus main  
>> page)?  If so, what are the pros and cons to moving to this?
>
> xbean is what activemq 4.x and servicemix 2.x are using for wiring  
> up it's components.  I think the the openejb folks are also jumping  
> on and starting to use it too.  Seems like Dan from xfire, has  
> started to also drive requirements into so I guess xfire may start  
> using it soon too.

Currently, most people have been working with the XBean Spring  
package with provides a simpler xml configuration system for Spring  
(http://xbean.org/Custom+XML).  The real draw of this technology is  
that is provides backwards compatibility with existing Spring and  
other configuration systems, so that a user does not need to rewrite  
everything at once to see the benefit.  This is a philosophy we carry  
through the project.

>> Does OSGi compete with/overlap Xbean functionality? If so is it  
>> premature to consider Xbean before we have considered OSGi?
>
> I've got a feeling it's complimentary.  ActiveMQ and servicemix  
> only uses xbean for configuration wiring.  The one thing I'm  
> keeping an eye on OSGi is for it's classpath/native library  
> management (would come in handy for servicemix).

Ya they are complimentary technologies.  OSGi use is similar to JMX  
in that we don't replace or compete with JMX, we work with it and try  
to ease the user experience of working with the technology.  In the  
case of OSGi, I'd like to provide a seamless transition from existing  
configurations, which use a hierarchal class loader structure, to the  
more network style of the OSGi class loader system.

-dain

Mime
View raw message