geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: How to map the lifecycle between blueprint and configuration ?
Date Tue, 23 Nov 2010 17:25:53 GMT

On Nov 22, 2010, at 11:46 PM, Ivan wrote:

> 2010/11/23 David Jencks <>
> Hi Ivan,
> I didn't think there was a way to explicitly get a bundle into the "resolved" state.
 Did I miss something?  It was quite a long time ago but I think this was the reason I didn't
pursue the mapping you suggest.
>     Seems that call the bundle.loadClass(Object.class.getName()) would force the framework
to resolve the bundle, so far it works for me.

I didn't think of that :-)

>     Now, I am trying to use a ConfigurationExtender to load the ConfiguationData from
the bundle while it receives the RESOVLED status, and remove those activator from the car
package, in this way, it should more OSGI friendly.    

very good idea...

> I wonder how serious this problem is and if we should wait to see what a gbean-free geronimo
looks like?
>     I am not quite sure for it. Seems that ImportType.CLASS is not widely used, I only
found them in the client and cluser modules. For the duplicate ObjectFactory service, it might
work, but another extra javax.naming.spi.InitialContextFactory service for OpenEJB remote
client is also published, not sure whether it would break anything.

In general the builder/deployer plugins are supposed to have these ImportType.CLASS dependencies
on the runtime plugins they build stuff for, e.g jetty8-deployer having a CLASS dependency
on jetty8.  This is so when you build a web app plugin for jetty for example using the car-maven-plugin
you don't actually start up a jetty server during your build.

>     I would try it for a while, if too much staff is required, I could turn to other
ways, maybe just update the pom files for a temp workaround. But guess that we still need
this change for a gbean-free geronimo ...
>     thanks.    

I think if you can make this work fairly easily it will really improve the geronimo-osgi integration.
 I hope it works :-)

david jencks

> thanks
> david jencks
> On Nov 22, 2010, at 10:06 PM, Ivan wrote:
>> I am thinking that, do we need to seperate the Configuration with its sub gbeans
now ? Currently, we start the Configuration gbean in the load process, and start the sub gbeans
in the start process, I guess that in the past, we need this, as sometimes it is just required
the classloader work, not the gbean service. But now, in OSGI, once those bundles are resolved,
they are ready for class loading request. 
>> Now, I am trying to make the mapping like :
>> resolved  -> load configuration data
>> started   -> configuration gbean + sub gbeans + blueprint service
>> Not sure whether I miss anything, please help to point it out, so that I could save
some time, thanks. 
>> 2010/11/22 Ivan <>
>> Hi,
>>     When looking at GERONIMO-5579, I found that in the full profile, there are duplicate
JNDI services are published in the server runtime, and those unwanted ones are from client
module. In the past, we use ImportType.CLASS to make the class loading ready, so those sub
gbeans are not started. But now, those JNDI configurations are from blueprint configurations,
and they are published once the bundle is started, and the Configuration is also loaded after
the Bundle is started.
>>     I think that the blueprint service in the car plays the same role as those sub
gbeans, is it possible to change the lifecycle mapping relation ?
>>    bundles     plugins
>>    installed     plugin installed
>>    resolved    configuration gbean started
>>    started      configuration gbeans started + blueprint service  
>>    or just remove dependency client module from the client-deployer, and copy all
the dependencies from the client module to client-deployer module, 
>>    Thoughts ?
>> -- 
>> Ivan
>> -- 
>> Ivan
> -- 
> Ivan

View raw message