geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: How to map the lifecycle between blueprint and configuration ?
Date Thu, 13 Jan 2011 02:23:38 GMT
I just found there is a 'start' attribute in the dependencyType, when will
it be used ? Seems I did not find useful example for it.
thanks.

2011/1/13 Ivan <xhhsld@gmail.com>

> I have worked on this issue for some time, now, most codes have been done.
> But I am thinking that we need to add a new configuration item to the
> dependency configuration, like
> -->
> <dependency>
>                             <groupId>org.apache.geronimo.specs</groupId>
>                             <artifactId>geronimo-jaxb_2.2_spec</artifactId>
>                             <start>eager</start>
>                         </dependency>
> <---
> If a dependency is marked as eager start, we would start them once they are
> installed.
>
> The reason is that, resolved state for classloading is enough for most
> bundle, but for our spec API and impl, it is not enough, as you might know,
> we use the OSGi track to check all the service provider and keep them in a
> registry service, so we need to start those bundles, or they could not work
> correctly.
> Thoughts ?
> Thanks.
>
>
> 2010/11/24 David Jencks <david_jencks@yahoo.com>
>
>
>> On Nov 22, 2010, at 11:46 PM, Ivan wrote:
>>
>>
>> 2010/11/23 David Jencks <david_jencks@yahoo.com>
>>
>>> 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 :-)
>>
>> thanks!
>> 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 <xhhsld@gmail.com>
>>>
>>>> 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
>>
>>
>>
>
>
> --
> Ivan
>



-- 
Ivan

Mime
View raw message