I think it would be fair to assume that the org.osgi.core packages are
shared from the initiating classloader - the one that kicks off the
framework launcher. This is what the TCK does too, it puts these
packages explicitly on the org.osgi.framework.system.packages.extra
property and this is how I have it currently implemented.
I originally implemented a bridging approach where these classes were
separate (so one instance of class X owned by the caller and one
instance of class X owned by JBoss Modules) but this doesn't work when
you are passing objects created by JBOSGi back into framework APIs. For
example, if you call BundleContext.getService(ServiceReference sr) our
implementation actually expect our own ServiceReferenceImpl to be passed
in, which clearly doesn't work with the bridging approach (or it will
get very complicated).
Cheers,
David
On 09/10/2012 15:40, Thomas Diesler wrote:
Hi David,
I'm wondering how the org.osgi.core class sharing is supposed to work
with this. If the AS7 internal framework is getting those types from
the org.osgi.core module and the launcher/client gets them from the
syscp they cannot be assigned - so the client could not
consume/provide those types through the framework API.
cheers
--thomas
> On 10/09/2012 09:57 AM, David Bosschaert wrote:
>>
>> This can only be done with value types from the syscp, right?
>>
>> Yes, correct.
>>
>> This code should not not be needed
>> if (ctrl.getMode() == Mode.ACTIVE)
>> return ctrl.getValue();
>> ctrl.setMode(Mode.ACTIVE);
>>
>> I don't follow what you mean here? Where are you seeing that code?
>> Or what is it a replacement for?
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx