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