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 <[email protected]> > 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 <[email protected]> > > >> 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 >> >> >> > > > -- > Ivan > -- Ivan
