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 2010/11/22 10:23:03 UTC
How to map the lifecycle between blueprint and configuration ?
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
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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by 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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by 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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by Ivan <xh...@gmail.com>.
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.
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.
>
> 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.
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.
>
> 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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by 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.
I wonder how serious this problem is and if we should wait to see what a gbean-free geronimo looks like?
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
Re: How to map the lifecycle between blueprint and configuration ?
Posted by Ivan <xh...@gmail.com>.
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