> On 14 Jan 2016, at 12:19, Malek Ben Salem <malek-ben.sa...@aicas.de> wrote: > > Yes, I use the same location string. Is there another way to do this?
So this is the problem. As you quoted yourself: "Every bundle is uniquely identified by its location string. If an installed bundle is using the specified location, the installBundle methods must return the Bundle object for that installed bundle and not install a new bundle”. Therefore Felix is behaving correctly. To pass a different location string, you can use the two-argument variant of installBundle(), i.e. the one that takes an InpuStream as its second arg. Now you can treat the location as an opaque string, as it no longer has to be a URL for the bundle data. I recommend using some kind of URN. > > Shouldn't the framework just ignore the existing location if the bsnversion > switch is set to multiple? I mean, why bother "allow multiple bundles to be > installed having the same symbolic name and version" if the install method > will refuse it before checking? This is how I understand the spec, so I > changed my build to check the switch before eventually looking for the > location and then just do one thing or the other (return the existing bundle > or install a new one). No it shouldn’t. As the spec clearly states, the location string must be unique even when bsnversion=multiple is enabled. In many ways the location string is the ultimate “primary key” of a bundle. Regards, Neil > > Regards, > Malek. > > On 01/13/2016 03:40 PM, Neil Bartlett wrote: >> Do you pass a unique location string each time you install? >> >> Neil >> >> >>> On 13 Jan 2016, at 12:12, Malek Ben Salem <malek-ben.sa...@aicas.de> wrote: >>> >>> Hi everyone, >>> >>> I'm trying to start many instances of the same bundle in one OSGi. I have >>> noticed that setting org.osgi.framework.bsnversion=multiple doesn't change >>> anything. The install command returns the ID of the already installed >>> bundle, no new bundle is installed, as specified in 4.4.3 of the OSGi Core >>> Release 6 Spec: >>> >>> "Every bundle is uniquely identified by its location string. If an >>> installed bundle is using the specified >>> location, the installBundle methods must return the Bundle object for that >>> installed bundle and not install a new bundle." >>> >>> Yet the same section also says: >>> >>> "If the to be installed bundle has a bundle symbolic name and version pair >>> that is already installed in >>> the framework then the installation is only valid when the >>> org.osgi.framework.bsnversion framework launching property is set to >>> multiple or managed." >>> >>> Section 10.1.15.49 (concerning org.osgi.framework.bsnversion=multiple) >>> actually says this should be possible: >>> "Specifies the framework will allow multiple bundles to be installed having >>> the same symbolic name and version." >>> >>> So, is this a bug in the framework? I actually use my own build of the >>> framework where I changed the installBundle method of >>> org.apache.felix.framework.Felix.java to force this option to work. I still >>> would like to know the better way to achieve this or to have the bug >>> corrected. >>> >>> Regards, >>> Malek. >>> >>> -- >>> aicas GmbH >>> Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany >>> http://www.aicas.com * Tel: +49-721-663 968-0 >>> >>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim >>> Geschäftsführer: Dr. James J. Hunt >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > -- > aicas GmbH > Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany > http://www.aicas.com * Tel: +49-721-663 968-0 > > USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim > Geschäftsführer: Dr. James J. Hunt > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
