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 <xhh...@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
