Re: [equinox-dev] Eclipse DSDP/MTJ Bundle Loader Hooks Trouble in Galile

[Thomas Watson <tjwatson@xxxxxxxxxx>]

The BundleLoader class is an internal (non-API) class of equinox which we refactored into another package in 3.5 (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=246132). The BundleLoader class now lives in the org.eclipse.osgi.internal.loader package. You will have to import that package instead of the org.eclipse.osgi.framework.internal.core package to use the addDynamicImportPackage method.

Tom



Craig Setera ---01/15/2009 07:35:31 PM---Hello Eclipse Runtime experts,

From:	Craig Setera <craigjunk@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	01/15/2009 07:35 PM
Subject:	[equinox-dev] Eclipse DSDP/MTJ Bundle Loader Hooks Trouble in Galileo

---

Hello Eclipse Runtime experts,

In order to provide preprocessor support for low-end Java devices/ 
phones, EclipseME/MTJ has hooked into JDT by using a Classloader hook  
for a few releases.  This has worked fine until recent Galileo  
builds.  One of our users let us know that our runtime hooks are no  
longer working on the Galileo builds.  The exception stack trace the  
user is seeing is:

> Caused by: java.lang.NoClassDefFoundError: org/eclipse/osgi/ 
> framework/internal/core/BundleLoader
> 		 at  
> org 
> .eclipse 
> .mtj.core.hooks.MTJClassLoadingHook.createClassLoader(Unknown Source)
> 		 at  
> org 
> .eclipse.osgi.baseadaptor.BaseData.createClassLoader(BaseData.java:92)
> 		 at  
> org 
> .eclipse 
> .osgi.internal.loader.BundleLoader.createBCL(BundleLoader.java:821)
> 		 at  
> org 
> .eclipse 
> .osgi 
> .internal.loader.BundleLoader.createBCLPrevileged(BundleLoader.java: 
> 810)
> 		 at  
> org 
> .eclipse 
> .osgi 
> .internal.loader.BundleLoader.createClassLoader(BundleLoader.java:356)
> 		 at  
> org 
> .eclipse 
> .osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:317)
> 		 at  
> org 
> .eclipse 
> .osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java: 
> 227)
> 		 at  
> org 
> .eclipse 
> .osgi 
> .framework 
> .internal 
> .core.AbstractBundle.loadBundleActivator(AbstractBundle.java:142)
> 		 ... 10 more

The hook is configured using:

public void addHooks(HookRegistry hookRegistry) {
         if (Debug.DEBUG_GENERAL) {
             System.out.println("Adding MTJ class loading hook");
         }

         hookRegistry.addClassLoadingHook(new MTJClassLoadingHook());
     }


The offending code:

public BaseClassLoader createClassLoader(ClassLoader parent,
             ClassLoaderDelegate delegate, BundleProtectionDomain  
domain,
             BaseData data, String[] bundleclasspath) {
         boolean isJdtCore = "org.eclipse.jdt.core".equals(data
                 .getSymbolicName());
         boolean isEclipseBundleLoader = delegate instanceof  
BundleLoader;

         // If the bundle loader is of the current type and is for
         // the JDT core bundle, we will go ahead and force an OSGi  
"wire"
         // back to our package implementation from the JDT plug-in.
         if (isEclipseBundleLoader && isJdtCore) {
             if (Debug.DEBUG_GENERAL) {
                 System.out
                         .println("Adding dynamic import into JDT Core  
bundle");
             }

             try {
                 ManifestElement[] dynamicElements = ManifestElement
                         .parseHeader("DynamicImport-Package",
                                  
"org.eclipse.mtj.core.hook.sourceMapper");
                 ((BundleLoader) delegate)
                         .addDynamicImportPackage(dynamicElements);
             } catch (BundleException e) {
                 if (Debug.DEBUG_GENERAL) {
                     e.printStackTrace();
                 }
             }
         }

         // Let the framework know that we did not create the  
classloader
         return null;
     }

Any insights into how we can resolve these issues would be  
appreciated.  I've noticed discussion of the new OSGi ServiceHooks  
features and I didn't know if it was somewhat related.

Thanks,
Craig

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev