Announcement Announcement Module
Collapse
No announcement yet.
Buddy Classloading Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Buddy Classloading

    Eclipse have a buddy classloading feature that allow us to solve the Class.forName problem in osgi bundles who dynamic load classes from the context loader. (http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements)

    I am not familiar with how this feature works. Does it come with the eclipse osgi core jar? I tried adding "Eclipse-BuddyPolicy: registered." into the manifest of com.springsource.org.castor and have my bundle register it as buddy. I am still getting ClassNotFoundException in my bundle when it tried to map its class using spring oxm. (ClassNotFoundException is thrown from org.castor mapping, because it is looking at the my resource in its own classloader.)

    Also, since this is not a osgi spec, do we want to avoid using this feature? I continue to see some patterns in many open source library that is using Class.forName to dynamic loading a class. I had to hack some of their manifest to purposely import the classes it needs. This is not an ideal solution.

    Thanks,

    mc

  • #2
    Buddy Classloading

    In my project, I was very successful with using fragments to enrich the class-space of 3rd party bundles. For example, to make custom persistent entities available to Hibernate, I used the following MANIFEST.MF:
    ...
    Fragment-Host: com.springsource.org.hibernate;bundle-version="3.2.6"
    Import-Package: com.organisation.project.entities;version="1.0.0"; resolution:=optional,
    ...
    This OSGi-compliant 'trick' works in most similar situations, too, without requiring to modify the original bundle.

    Regards, Alex

    Comment


    • #3
      Buddy Classloading

      Try using the context class loading support in the SpringSource Application Platform. For example, if an application packaged as a PAR calls a 3rd party bundle that loads classes from the context class loader, then it should be sufficient for application bundles to export any of their packages that need to be available for context class loading. All the packages exported by bundles of a PAR are loadable by the context class loader.

      Comment


      • #4
        Buddy Classloading

        I am not aware any context class loading support in SpringSource AP. There is a context-class-loader attribute in spring dm that allow you to pass the context class loader to have visibility to all resources, but that is not going to solve the problem that I am having. I am facing a similar problem with C3P0.

        https://issuetracker.springsource.com/browse/BRITS-89.

        Comment


        • #5
          Buddy Classloading

          Did you try my suggestion to use fragments which add dependencies to existing library bundles dynamically at runtime? For me, this approach has the following advantages:
          - OSGi-compliant (on platforms which support fragments)
          - no modification of existing bundles required
          - no usage of 'magic' classloading hooks or proprietary extensions
          - explicit specification of dependencies in fragment manifest

          On the other hand, there are only a few drawbacks I can think of:
          - potentially large number of fragments required (depending on size and complexity of the project)
          - it is necessary to adjust the bundle host in the fragment manifest if there is an update to the library bundle

          In my opinion, this seems to be favorable tradeoff - but I'm alway interested in discussion or a proposal of better alternatives.

          Comment


          • #6
            Buddy Classloading

            I didn't try your suggestion, because I didn't think it will make sense for my bundle to be a fragments of org.castor. My bundle is using spring oxm to convert the object to xml, which uses castor to do the mapping. I feel awkward when my bundle is fragment of something that it indirectly uses.

            Comment


            • #7
              Buddy Classloading

              I understand your concerns - actually, I suggest to introduce a separate fragment which only contains the specification mentioned above (no class files or other ressources). It only specifies the required dependency on your package(s) which exists at runtime. Your original bundle with persistent entities, business logic etc. remains unmodified.

              BTW, Costin Leau mentions other possible drawbacks to this approach in http://forum.springframework.org/showthread.php?t=57596.

              Comment

              Working...
              X