>> >>> 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 --00248c0501e582c5eb0499b036e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 depen= dency configuration, like
-->
<dependency>
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <g= roupId>org.apache.geronimo.specs</groupId>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 <artifactId>geronimo-jaxb_2.2_spec</artifactId>
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 <start>eager</start>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </dependency>
<---
If a= dependency is marked as eager start, we would start them once they are ins= talled.

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 wor= k correctly.
Thoughts ?
Thanks.

2010/11/24 Davi= d Jencks <da= vid_jencks@yahoo.com>

On No= v 22, 2010, at 11:46 PM, Ivan wrote:

2010/11/23 David Jencks <<= a href=3D"mailto:david_jencks@yahoo.com" target=3D"_blank">david_jencks@yah= oo.com>

Hi Ivan,

I didn= 9;t think there was a way to explicitly get a bundle into the "resolve= d" state. =A0Did I miss something? =A0It was quite a long time ago but= I think this was the reason I didn't pursue the mapping you suggest.

=A0 =A0 Seems that call the bundle.loadClass(Ob= ject.class.getName()) would force the framework to resolve the bundle, so far it works for me.

I didn't think of that :-)

=A0 =A0 Now, I am trying to use a ConfigurationExtender to load the Co= nfiguationData from the bundle while it receives the RESOVLED status, and r= emove those activator from the car package, in this way, it should more OSG= I friendly. =A0=A0
=A0

very good idea...

I wonder how seri= ous this problem is and if we should wait to see what a gbean-free geronimo= looks like?

=A0 =A0 I am not quite sure for it. Seems that = ImportType.CLASS is not widely used, I only found them in the client and cl= user modules. For the duplicate ObjectFactory service, it might work, but a= nother extra javax.naming.spi.InitialContextFactory service for OpenEJB rem= ote client is also published, not sure whether it would break anything.

In general the builder/deploy= er plugins are supposed to have these ImportType.CLASS dependencies on the = runtime plugins they build stuff for, e.g jetty8-deployer having a CLASS de= pendency on jetty8. =A0This 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 j= etty server during your build.

=A0 =A0 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 ...
=A0 =A0 thanks. =A0=A0

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

thanks!

david jencks

=A0
=

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 lo= ad 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 wo= rk, not the gbean service. But now, in OSGI, once those bundles are resolve= d, they are ready for class loading request.
Now, I am trying to make the mapping like :
resolved=A0 -> load confi= guration data
started=A0=A0 -> configuration gbean + sub gbeans + blu= eprint 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,
=A0=A0=A0 When looking at GERONIMO-5579, I found that in the full pr= ofile, there are duplicate JNDI services are published in the server runtim= e, and those unwanted ones are from client module. In the past, we use Impo= rtType.CLASS to make the class loading ready, so those sub gbeans are not s= tarted. But now, those JNDI configurations are from blueprint configuration= s, and they are published once the bundle is started, and the Configuration= is also loaded after the Bundle is started.
=A0=A0=A0 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 relati= on ?
=A0=A0 bundles =A0=A0=A0 plugins
=A0=A0 installed =A0=A0=A0 plug= in installed
=A0=A0 resolved=A0=A0=A0 configuration gbean started
=A0=A0 started =A0 =A0=A0 configuration gbeans started + blueprint service= =A0

=A0=A0 or just remove dependency client module from the client-= deployer, and copy all the dependencies from the client module to client-de= ployer module,
=A0=A0 Thoughts ?
=A0=A0
--
Ivan

--
Ivan

--
Ivan

--
Ivan
--00248c0501e582c5eb0499b036e2--