HOWTO chage the behaviour of the CL policy

[thomas.diesler]

Currently bundle class loading uses VFSClassLoaderPolicy, which seems to load the class from the private packages first rather than considering imports.

This is related to

https://jira.jboss.org/jira/browse/JBOSGI-135

How can I configure/swap the policy being used?

More specifically I see in BaseClassLoaderDomain that

 Loader findLoaderInImports(ClassLoaderInformation info, String name, boolean trace)
 {
 List<? extends DelegateLoader> delegates = info.getDelegates();
 if (delegates == null || delegates.isEmpty())
 {
 if (trace)
 log.trace(this + " not loading " + name + " from imports it has no delegates");
 return null;
 }

does not have delegates for imports.

At the end of the day I want org.apache.felix.log.jar to load [org.osgi.service.log.LogService] from org.osgi.compendium.jar

You can reproduce the issue by running

[tdiesler@tdvaio trunk]$ mvn -Dtest=SimpleLogServiceTestCase test

Running org.jboss.test.osgi.integration.simple.SimpleLogServiceTestCase
FIXME [JBOSGI-135] Cannot handle package beeing imported and exported by the same bundle
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.355 sec

[adrian.brock]

This test is currently broken for me.

But if there is a PackageRequirement there should be a delegate
(which the OSGi spec calls a "wire").

Although you have put some code that weeds out system packages that I don't understand?

My understanding was that non-core api had to be referenced using Import-Package
e.g. the logging or compendium api.
and that this would resolve to the implementing (extension) bundle - possibly the system bundle?

[thomas.diesler]

My understanding was that non-core api had to be referenced using Import-Packag

Actually core API needs to have a wire too. That is why Felix and Equinox ship their frameworks as bundles that contain the core packages and versions in Export-Package directives.

This proper fix would probably be to install some global PackageCapabilities that correspond to the system packages that are configured in the SystemPackagesPlugin

[adrian.brock]

So let's do it the same way. I haven't really looked at this part of the spec yet
but its certainly something I planned to address.

There's no reason why the SystemBundle classloader couldn't be defined in the
bootstrap to expose the osgi core packages (and maybe some services)
instead of letting them bubble up to the "classpath" using the parent policy.

The other services would just be deployed as bundles.

i.e. just make the parent policy in OSGiClassLoaderSystem
ParentPolicy.BEFORE_BUT_JAVA_ONLY
then have the following in the bootstrap.xml to be the "system bundle classloader"

<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <classloader><inject bean="system-bundle:4.4.2" /></classloader>

 <classloader name="system-bundle"
 version="4.4.2"
 xmlns="urn:jboss:classloader:1.0"
 >
 <root>${jboss.lib.url}osgi-core.jar</root>
 <root>${jboss.lib.url}jboss-osgi-impl.jar</root>
 <capabilities>
 <package name="org.osgi.framework" version="1.4.0"/>
 <package name="org.osgi.service.packageadmin" version="1.2.0"/>
 <etc./>
 </capabilities>
 </classloader>