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
