You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ivan <xh...@gmail.com> on 2011/01/13 02:26:54 UTC
Re: How to map the lifecycle between blueprint and configuration ?
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 <da...@yahoo.com>
>
> On Nov 22, 2010, at 11:46 PM, Ivan wrote:
>
>
> 2010/11/23 David Jencks <da...@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 <xh...@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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by Ivan <xh...@gmail.com>.
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 <xh...@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 <da...@yahoo.com>
>
>
>> On Nov 22, 2010, at 11:46 PM, Ivan wrote:
>>
>>
>> 2010/11/23 David Jencks <da...@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 <xh...@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