Yes, that's it. Looking at EmbeddedOSGiFrameworkLauncher
you generate that list from
Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA and then add a few hard
coded bits too it. IIRC, that property lists the packages that the
system bundle exports and not what is delegated at CL level.
What you probably want to use instead is Constants.FRAMEWORK_BOOTDELEGATION.
The values in the configuration map given to launch(Map) should
probably just be copied/merged with the subsystem configuration.
Otherwise the framework will not have the correct view of the
framework launch properties.
On 10/10/2012 10:45 AM, David
Bosschaert wrote:
These
packages are passed to the "jboss.modules.system.pkgs" system
property which is set before the boot module loader is created:
https://github.com/jbossas/jboss-as/blob/master/embedded/src/main/java/org/jboss/as/embedded/InitialModuleLoaderFactory.java#L66
Cheers,
David
On 09/10/2012 17:16, Thomas Diesler wrote:
> I think it would be fair to assume
that the org.osgi.core packages are shared from the initiating
classloader
sure, but how does this work? The osgi subsystem loads the
framework from a module which loads the org.osgi.framework
packages from another module. The osgi system packages that can
be configured through framework properties still come from the
modules hierarchy and not from the syscp. So I wonder how
anything except java.* and some system packages defined though
Modules can be used from outside the AS.
On 10/09/2012 05:12 PM, David Bosschaert wrote:
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx