2

I am busy with R&D with osgi and its role in the technology stack. I buy into the whole modularity and benefits this gives from a software component standpoint. Now, what I am battling to get my head around is the practical elements of the following statement

"An interesting feature of OSGi is multiple versions of a bundle can be deployed to the same container. All the bundles deployed in an OSGi container run in one JVM"

This is ideal and really truly a requirement for me, however in practical terms is this even feasible if we speak about software components managing data. So it makes sense to have multiple versions of a bundle deployed (or at least backward compatible versions) but if that component is managing data or a resource..what are we saying are the implications to the data and resource layer. Do they equally have to have multiple and cohesive versions of themselves simultaneously in the container. If 2 bundles exist where they are minor versions, but there was a significant constraint imposed on the resource/data layer imposed in the 2nd bundle data schema...wouldn't this pose a problem.

My question is how far can this really go. Is it a case of ensuring we always have the 1 of the major bundles deployed and look to having minors co-exist in parallel. I am concerned that there is attention paid to the actual physical jar bundle itself...but no attention paid to the actual data/resource is has mandate over.

Anyone come across this dilemma before?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Roger
  • 21
  • 3

1 Answers1

1

It depends what the bundles does as to whether having 2 versions side-by-side is practical. For example 2 versions of an XML parser is OK. But 2 version of SWT (in Eclipse) is not ok since SWT manages the display resource. This is why some bundles are marked as singletons to indicate the manage some single resource.

BJ Hargrave
  • 9,324
  • 1
  • 19
  • 27