Announcement Announcement Module

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
Shared Domain Model Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Shared Domain Model

    I have a generic OSGi question (please point me to a better forum if you know one).

    Suppose that you have a generic client/server system running in different OSGi containers. Then you have (at least) a client OSGi bundle and a server OSGi bundle. Because they are generic, these bundles do not depend on the domain model bundle, but know how to use reflection and possibly byte code enhancement to work with domain model classes. This means we have (at least) TWO OSGi bundles which need to be able to load classes from a common domain model bundle WITHOUT explicitly depending on the bundle.

    I know this can be solved for Equinox by buddy loading. If there was only the server, it could be solved with Fragments, but fragments cannot have multiple hosts! Even worse, if the domain model has to have an Activator of its own this doesn't work.

    Is there a generic OSGi way to solve this problem cleanly, or is buddy loading the best answer?

    I see two generic OSGi solutions with large disadvantages:
    - Explicitly add specific domain model dependency to the generic system. Drawbacks: unwanted dependency, need to repackage the generic system for each different domain model.
    - Use services to communicate between domain model and generic system. Drawback: generic system needs to be able to build and load unknown classes at runtime through service interfaces which definitely feels like a hack or security issue.

  • #2
    Alternatively you could create some OSGi generic infrastructure which "breaks" the bundle and looks for bundle that expose the classes you want (potentially through Package Admin) and then they import it.
    The problem here is that you're bypassing OSGi so you have to do some management of your won which might prove problematic in some cases.