geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Whence the geronimo kernel?
Date Thu, 12 Mar 2009 10:41:51 GMT
On 12/03/2009, at 5:26 AM, David Jencks wrote:

>
> On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote:
>
>> Hi,
>>
>> FWIW, I believe that improving the configuration style to simplify  
>> the means of creating a bunch of objects in the kernel has more  
>> benefits than swapping the classloading infra. On paper OSGi may  
>> appear as superior from a classloading isolation perspective;  
>> however, I believe the current CLing design is nearly up to par  
>> with the OSGi one and that the main challenge is to properly tune  
>> export/import dependency declarations.
>>
>> The JAXB approach to turn xml plans to a bunch of objects is  
>> certainly interesting. I believe it is still a technology limiting  
>> decision whereby a lot of custom code will have to be implemented  
>> to support various style (factory methods or beans et cetera) of  
>> configurations. I have been bouncing around this idea a while back  
>> and here it is again. Why do we want to define a XML language to  
>> create a bunch of objects when scripting can do that for us?
>>
>> I believe that xbean-spring is still unnecessary noisy when  
>> compared to something like the Spring Bean Builder (http:// 
>> www.grails.org/Spring+Bean+Builder).
>
> That looks nice, but is there any syntax validation possible?  I'm  
> pretty much unwilling to use groovy for anything at this point due  
> to my bad experiences with lack of pre-runtime syntax validation  
> and unclear error messages writing some simple gshell commands.   
> xml is really horrible but most editors do support validation  
> against a schema.

This is the weakness but also the power of the approach whereby users  
can mix arbitrary code and declarations. Syntax validation is pretty  
much addressed by IDEs; however, only testing the script will prove  
that it does what it is supposed to do. I do understand your  
reticence thought and I will not insist.


>
> On the other hand, I think we could come up with something even  
> shorter, clearer, and to the point, with syntax validation, using  
> scala.
>

This is an interesting idea. I am keen to see something more  
streamlined and efficient than yet another XML approach to configure  
a bunch of services in the kernel!

Thanks,
Gianny

> thanks
> david jencks
>
>>
>> If there is an interest in a scripting approach, then I can  
>> investigate further.
>>
>> Thoughts?
>>
>> Thanks,
>> Gianny
>>
>> On 11/03/2009, at 6:54 AM, David Jencks wrote:
>>
>>> So as mentioned below I'm starting to look into the osgi  
>>> classloading bit, sort of "from the bottom".
>>>
>>> Another approach to many of these issues is perhaps "from the  
>>> top", from the point of view of going from a presumably xml plan  
>>> to a bunch of objects.
>>>
>>> I've long thought that it must be possible to leverage jaxb to do  
>>> most of the heavy lifting here.  In particular sxc is some code  
>>> we can presumably actually extend to do stuff like constructor  
>>> dependency injection.  So another avenue that could perhaps be  
>>> approached in parallel would be to investigate sxc, jaxb, xbean- 
>>> spring, xbean-reflect, the blueprint service schema, and jsr299  
>>> requirements and see what we can come up with.
>>>
>>> For instance, it might be possible to have a large part of the  
>>> blueprint service functionality in jaxb-enabled objects that jaxb  
>>> instantiates from the xml.  The "init" method could deal with  
>>> feeding the metadata into the blueprint service core.  Maybe we  
>>> can get sxc to use xbean-reflect to create the objects.
>>>
>>> So far this is more or less wild speculation in my head...  but I  
>>> think it would be a lot of fun to investigate.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>> On Mar 4, 2009, at 4:56 PM, David Jencks wrote:
>>>
>>>> Geronimo has been around for a while and despite the many good  
>>>> features gbeans and the geronimo kernel are not catching on big  
>>>> time.  I think we want to consider taking action now to avoid  
>>>> ending up being dragged down by supporting a dead container.   
>>>> Here are a few thoughts.
>>>>
>>>> Actual problems with geronimo:
>>>> - gbeans are too restrictive.  It's too hard to instantiate  
>>>> other peoples components as gbeans.  GBeans don't support common  
>>>> patterns like factory methods, factory beans, etc etc, and  
>>>> require the component to be instantiated directly by the gbean  
>>>> framework.
>>>> - it's too hard to get the classloaders to work.  The most  
>>>> common problem is a class cast exception due to loading the same  
>>>> jar in two plugins.  NoClassDefFound errors from an optional jar  
>>>> in a child classloader are also really annoying.
>>>>
>>>> Really good things about geronimo I haven't seen elsewhere (at  
>>>> least in one place):
>>>> - gbean dependencies work across plugins.  Dependencies are a  
>>>> unified system, not per-plugin.
>>>> - gbean dependencies are resolved in the ancestors of a plugin,  
>>>> not server wide.  This means that you can't make a partially  
>>>> specified dependency ambiguous by deploying additional plugins.   
>>>> I consider this an extremely important feature for predictability.
>>>> - plugin dependencies allow assembly of a server from the  
>>>> explicit dependencies which are normally the same as the maven  
>>>> dependencies.
>>>>
>>>> Other projects and specs that have stuff we should look into:
>>>> maven.  Maven has a lot better infrastructure for dealing with  
>>>> dependency resolution from partial transitive dependency  
>>>> specification than we do.  We should look into using more of  
>>>> their infrastructure.
>>>> osgi. osgi has a lot of similarities to geronimo. The osgi  
>>>> classloading model is getting a lot of people excited.  The  
>>>> import-bundle idea is pretty much the same as our classloader  
>>>> model where every jar is a plugin.  I don't know if people are  
>>>> really using the allegedly recommended method of specifying  
>>>> imports and exports and letting the osgi runtime figure out  
>>>> where they come from; this seems worth investigating to me.  
>>>> Also, we get periodic inquiries about when we are going to  
>>>> support osgi and the was ce folks get even more.
>>>> osgi blueprint service (rfc 124) This appears to be a simple  
>>>> wiring framework for a single plugin.  IIUC it uses the osgi  
>>>> service registry for component dependencies between bundles.
>>>> xbean-spring.  I'd be reluctant to try to implement a blueprint  
>>>> service that didn't provide the xbean-spring capabilities really  
>>>> well
>>>> ee6 dependency injection.  EE6 is going to have a pretty  
>>>> sophisticated dependency injection service which we'll need to  
>>>> support anyway.  We should try to figure out how much of the  
>>>> core we can assemble using it.
>>>>
>>>> Other great stuff we have:
>>>> xbean-reflect, xbean-finder, xbean-spring
>>>>
>>>>
>>>> These ideas have been floating around in my head for a long time  
>>>> and I've chatted with various people about them occasionally.    
>>>> While more discussion is certainly needed on everything here I  
>>>> need to do some implementation to understand much more.  So,  
>>>> what I'm planning to do:
>>>>
>>>> Dave's crazy work plan...
>>>> - Try to use the osgi classloader.  I think this involves  
>>>> putting the classloader creation in Configuration into a  
>>>> service.  Configurations will turn into osgi bundles.  I'll put  
>>>> the Kernel in the osgi ServiceRegistry so the Configuration  
>>>> bundle activator should be able to use it to resolve cross- 
>>>> plugin dependencies.
>>>> - try to figure out how maven dependency resolution fits into osgi.
>>>> - see if eclipse p2 is relevant for provisioning geronimo  
>>>> repositories
>>>>
>>>> at this point I think geronimo would be running on osgi, still  
>>>> using gbeans.
>>>>
>>>> - look into relaxing the gbean framework so it is more plugin-at- 
>>>> a-time rather than gbean-at-a-time
>>>> - see how that differs from the blueprint service, ee DI, and  
>>>> xbean-spring.  Try to support all of these at once.
>>>>
>>>> Thoughts? Counter proposals?  Anyone interested?
>>>>
>>>> many thanks
>>>> david jencks
>>>>
>>>
>>
>


Mime
View raw message