On Nov 22, 2010, at 11:46 PM, Ivan wrote: > > 2010/11/23 David Jencks <[email protected]> > 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 <[email protected]> >> 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
