[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Bootdelegation issue

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