[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

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@xxxxxxxxxx> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 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