Re: [equinox-dev] Bootdelegation issue

[Tim Diekmann <tdiekman@xxxxxxxxx>]

To further test my understanding, I added the import-package statement to the client bundle and also added a bundle to the runtime that exports the same package in the same version.
Now, the client does resolve against the bundle, but according to 3.9.3 step 2 of the core spec I would expect it to be "wired" to the class from the bootdelegation to the application class loader.

      Tim.

On Apr 18, 2011, at 1:46 PM, Tim Diekmann wrote:

> Thanks Neil,
> 
> it was my understanding from the spec that it should work.
> 
> There is no need to go into the merits of doing this. I have no plans of doing this deliberately and I know the appropriate way.
> However, if you don't own the code that gets installed into your runtime, then you may run into this once in a while. I wanted to confirm my understanding and verify the actual Equinox implementation.
> The next thing to try is to provide a bundle that exports the interface and ensure that the version from the classpath is chosen, because that is what the spec says. I.e. no bundle can override a package that comes from the bootdelegation.
> 
>      Tim.
> 
> On Apr 18, 2011, at 1:19 PM, Neil Bartlett wrote:
> 
>> Hmm. In theory this *should* work if you set the parent classloader to
>> app (because you have put the library you want on the application
>> classpath). Or you could add the library to the bootclasspath with
>> -Xbootclasspath.
>> 
>> However, why are you doing it this way? Assuming the library has to
>> live "outside" OSGi then it is better to export it via the system
>> bundle (i.e. using org.osgi.framework.system.packages[.extra]), and
>> then allow bundles to import it in the ordinary way.
>> 
>> This is better because it doesn't hide the dependency away inside the
>> bundle... if your bundle depends on certain packages being visible via
>> bootdelegation, how is the deployer of the bundle supposed to know
>> that?
>> 
>> Cheers
>> Neil
>> 
>> On Mon, Apr 18, 2011 at 9:00 PM, Tim Diekmann <tdiekman@xxxxxxxxx> wrote:
>>> Hi, I have a question about boot delegation in Equinox. My feeling is that
>>> it is not working according to the spec.
>>> The spec says:
>>> If the class or resource is from a package included in the boot delegation
>>> list (org.osgi.framework.bootdelegation), then the request is delegated to
>>> the parent class loader. If the class or resource is found there, the search
>>> ends.
>>> My test client uses a class that it does not import. According to the spec
>>> it is not necessary, since the fw has to delegate all packages to the parent
>>> class loader  if the package is listed in org.osgi.framework.bootdelegation.
>>> At runtime, it fails to load the APIClass.
>>> 
>>> 
>>> test client:
>>> package com.tibco.osgi.bootdelegation;
>>> import org.osgi.framework.BundleActivator;
>>> import org.osgi.framework.BundleContext;
>>> import com.tibco.osgi.bd.api.APIClass;
>>> /**
>>> * @author timd
>>> *
>>> */
>>> public class BootdelegationTest implements BundleActivator{
>>> @Override
>>> public void start(BundleContext context) throws Exception {
>>>        System.out.println(APIClass.getMessage());
>>> }
>>> @Override
>>> public void stop(BundleContext context) throws Exception {
>>> // TODO Auto-generated method stub
>>> 
>>> }
>>> }
>>> Manifest.mf (not importing the package!)
>>> Bundle headers:
>>> Bundle-Activator = com.tibco.osgi.bootdelegation.BootdelegationTest
>>> Bundle-ManifestVersion = 2
>>> Bundle-Name = Bootdelegation
>>> Bundle-RequiredExecutionEnvironment = JavaSE-1.6
>>> Bundle-SymbolicName = com.tibco.osgi.bootdelegation
>>> Bundle-Version = 1.0.0.201104181155
>>> Import-Package = org.osgi.framework;version="1.6.0"
>>> Manifest-Version = 1.0
>>> 
>>> test provider:
>>> package com.tibco.osgi.bd.api;
>>> /**
>>> * @author <a href="mailto:tdiekman@xxxxxxxxx";>Tim Diekmann</a>
>>> *
>>> * @since
>>> */
>>> public class APIClass {
>>>    public static String getMessage() {
>>>        return "This is from the system class loader";
>>>    }
>>> }
>>> Command line:
>>> java -classpath
>>> org.eclipse.osgi_3.7.0.v20110304.jar:com.tibco.osgi.bd.api_1.0.0.201104181140.jar
>>> -Dorg.osgi.framework.bootdelegation=com.tibco.osgi.bd.*
>>> org.eclipse.core.runtime.adaptor
>>> .EclipseStarter -console
>>> Result:
>>> java.lang.NoClassDefFoundError: com/tibco/osgi/bd/api/APIClass
>>> at
>>> com.tibco.osgi.bootdelegation.BootdelegationTest.start(BootdelegationTest.java:16)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
>>> Configuration:
>>> Equinox
>>>   org.eclipse.osgi_3.7.0.v20110304
>>> Java:
>>>  java version "1.6.0_24"
>>>  Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
>>>  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
>>> Any suggestions what I am missing here?
>>> I also tried the variant on the command line to change the parent class
>>> loader of the bundle class loaders to app and framework. No change. Adding
>>> the package to org.osgi.framework.system.packages.extra did not help either.
>>> java -classpath
>>> org.eclipse.osgi_3.7.0.v20110304.jar:com.tibco.osgi.bd.api_1.0.0.201104181140.jar
>>> -Dorg.osgi.framework.bootdelegation=com.tibco.osgi.bd.*
>>> -Dorg.osgi.framework.bundle.pare
>>> nt=app -Dorg.osgi.framework.system.packages.extra=com.tibco.osgi.bd.api
>>> org.eclipse.core.runtime.adaptor.EclipseStarter -console
>>> Thanks,
>>>      Tim.
>>> 
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>> 
>>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev