Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Eclipse DSDP/MTJ Bundle Loader Hooks Trouble in Galileo 
Thanks Martin,
In this case, it was just easier to use a bit of reflection to avoid the cast to the class that was moved without changing anything else around that. I've created and tested this approach and it is working well in 3.4 and 3.5 

Craig

On Jan 18, 2009, at 9:02 AM, Martin Lippert wrote:


Hi!
Just in case you don't need the full semantics of dynamic import you could also implement a ClassLoaderDelegateHook to do some extra classloading. For example if your hook is called for the jdt core bundle you could do some extra class lookup in your bundle.
We use this hook in equinox aspects to lookup additional types from other bundles when those dependencies are introduced by the load- time weaving. 

Just an additional idea...

Cheers,
-Martin




Thomas Watson wrote:
At the moment there is not. I know we have discussed adding a method to 
ClassLoaderDelegate to accomplish this but I cannot remember all the
reasons why we have not done so. Perhaps you should open a bug against Equinox->Framework to discuss this. But I am not promising an API solution 
at the moment ;-)
Thanks.
Tom
From : Craig Setera < craigjunk @setera .org > To : Equinox development mailing list <equinox- dev @eclipse .org > Date : 01/16/2009 09:03 AM Subject : Re: [equinox-dev] Eclipse DSDP/MTJ Bundle Loader Hooks Trouble in Galileo Tom , Thanks for the update. Is there a better (ie. not internal) way to do this 
that we should be using instead?
Thanks,
Craig
On Jan 16, 2009, at 7:59 AM, Thomas Watson wrote:
     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
<graycol.gif>Craig Setera ---01/15/2009 07:35:31 PM---Hello Eclipse 
     Runtime experts,
< ecblank.gif <ecblank.gif> > Craig Setera <craigjunk@xxxxxxxxxx> From : < ecblank.gif <ecblank.gif> > Equinox development mailing list <?equinox-dev@xxxxxxxxxxx > To : < ecblank.gif <ecblank.gif> > 01/15/2009 07:35 PM Date : < ecblank.gif <ecblank.gif> > [equinox-dev] Eclipse DSDP/MTJ Bundle Loader Hooks Trouble Subject: 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
     _______________________________________________
     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

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

Back to the top