I agree with Christian’s solution, and would add that the limitation of being exposed to at-most-one version of each type per bundle is a restriction of the underlying Java class loaders, not really OSGi at all.
Unless Java itself changes the way classes are loaded – highly unlikely since it would break lots of applications – then future versions of OSGi will all have the same restriction. Regards, Neil > On 12 Aug 2015, at 16:23, Christian Schneider <ch...@die-schneider.net> wrote: > > You can not simply import different versions of the same package into the > same bundle. Inside one classloader each class name must be unique. > The classloaders are only involved when the object is created though. > > So there is no problem to pass an A1.0.0 object into a method as Object. You > can then use reflection to work on the data. > In the same way you can use reflection to create the new A2.0.0 class. If you > need a classloader that can access e.g. A2.0.0 but do not want to import it > directly > you can search the bundle that offers the class and adapt the Bundle to > BundleWiring. From BundleWiring you can then get the classloader of the > bundle and use it > to create the A2.0.0 class. > > Additionally there is also the BundleRevision interface that allows you to > browse thorugh the exported packages if you do not know which bundle to use. > I have recently used this scheme in karaf to allow to create classes on the > karaf shell without using dynamic imports on the command bundle. > See > https://github.com/apache/karaf/commit/8f4ee1ff4370fcf8934364b7b104248ea914d08c > > <https://github.com/apache/karaf/commit/8f4ee1ff4370fcf8934364b7b104248ea914d08c> > > The method getBundleOfferingPackage returns the first bundle that offers any > version of the given package. This is a little simplistic of course as it > currently does not > allow to filter for versions but should show you how to do it. > > Christian > > Am 12.08.2015 um 08:50 schrieb Frank Langel: >> Hello, >> >> Allow a question >> >> Use Case : Data structure evolution >> application evolves, class A evolves from 1.0.0 to 2.0.0 >> Need to do an update and retrieve all data by mapping from A(1.0.0) —> >> A(2.0.0) >> How do I solve this use case >> Does OSGI, perhaps in its latest version, allow for it ? >> I understand that in previous versions, it wasn’t supported >> <http://stackoverflow.com/questions/18722932/can-an-osgi-bundle-or-package-depend-on-multiple-versions-of-another-bundle-or-p>http://stackoverflow.com/questions/18722932/can-an-osgi-bundle-or-package-depend-on-multiple-versions-of-another-bundle-or-p >> >> <http://stackoverflow.com/questions/18722932/can-an-osgi-bundle-or-package-depend-on-multiple-versions-of-another-bundle-or-p> >> >> Current solution >> >> I could use a canonical model A(1.0.0) —> C — > A(2.0.0) , where I would >> import A1.0.0 in Bundle b1, and A2.0.0 in Bundle b2, and C into B1 and b2, >> and then map A1.0.0 -> C and C —> A2.0.0, but I was wondering if there is an >> easier way and allow a point to point mapping without using the canonical >> class. >> >> I don’t think there is anything wrong with my current solution, but perhaps >> there is some functionality in the latest OSGI version that simplifies this? >> Thanks a lot >> Frank >> >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
