Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Use fragments to enrich class-space of 3rd party bundles (e.g. Hibernate) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Use fragments to enrich class-space of 3rd party bundles (e.g. Hibernate)

    After replying to a question on the S2AP forum, I would like to share an OSGi-compliant 'trick' for enriching the class-space of 3rd party bundles without modifying their manifest. This is a typical problem in persistence frameworks like Hibernate which require dynamic access to custom persistent entities during runtime. In this scenario, I successfully used fragments to make these classes (and associated XML-mappings) available, as illustrated in the following example with a fragment manifest:
    ...
    Fragment-Host: com.springsource.org.hibernate;bundle-version="3.2.6"
    Import-Package: com.organisation.project.entities;version="1.0.0"; resolution:=optional,
    ...
    After including this fragment in your OSGi runtime configuration, it will attach to the Hibernate master bundle and allows Hibernate to discover your entity classes (if available as a separate bundle with corresponding export of the package).

    This trick works in many similar situations, for example to add a suitable JDBC driver to the commons.dbcp bundle. Please excuse this proposal if it is already common knowledge (I did not read about it previously). Moreover, I would be happy to discuss possible drawbacks of this approach.

    Regards, Alex

  • #2
    Hi Alex,
    this is indeed a nice trick that should get you started.
    There are though some downsides with this approach:
    - the fragment host (hibernate) will keep seeing new classes as new fragments appear. This will cause a unified class space between the client classes which can lead to class incompatibilities. For example you cannot use the same library with more then one version of a certain package.
    - "manual" maintenance. This is more of an inconvenience but for every new client package added, you'll have to update the fragment as well. Not a major problem but if you have several packages in several bundles, maintaining the fragment can become a problem.

    Comment


    • #3
      Hello Costin,

      thank you for your reply to my suggestion. The unified class space is indeed a severe drawback which I did not consider previously. It would probably be acceptable if you don't anticipate to have multiple versions of these packages around at runtime (e.g. persistent classes which are usually tightly coupled to corresponding database structures). Do you know if other approaches like Dynamic-Import or Buddy-Classloading share this problem (I would guess they do)?

      The maintenance issue, in contrast, does not seem as severe to me. In my moderately sized project, I currently use only 3 fragments (2 for Hibernate, 1 for apache.commons.dbcp). If you forget to update these dynamic dependencies after a change to your packages, you will soon find out with lots of familiar exceptions during runtime ;-)

      Regards, Alex

      Comment


      • #4
        I think you'll have the same issue - I'm not sure if it applies for Buddy-ClassLoading but for sure it happens with DynamicImport. In fact, this is a potential downside of DynamicImport that you cannot tell what version was wired to your bundle when multiple are available.

        Comment


        • #5
          Hi Alex,
          we also use a fragment based approach for dealing with the Hibernate classloading issues. Before deciding to use fragments we also tried dynamic imports and buddy loading.
          Some days ago we stumbled upon an issue regarding PDE tooling in eclipse. Entities from one fragment had members defined in another fragment. These inter-fragment dependencies are not supported by PDE. You have to explicitly set the java build path, which does not feel very OSGi-ish.

          -- Jens

          Comment

          Working...
          X