On Thursday, 9 February 2012 at 18:10, Nicolas Roduit wrote:
>
> Thanks for your quick answer.
> > > Hi all,
> > >
> > > I've made an application with the latest release of Apache Felix
> > > framework and set the property "org.osgi.framework.storage.clean" to
> > > "none". Bundles are not loaded correctly when a bundle come from an
> > > different location of the one during the previous launch. Having
> > > different URLs for the same bundle seems to be an issue if the cache is
> > > not cleared.
> > > I see in log: Bundle symbolic name and version are not unique
> > >
> > > It is a client application deploy through Java Web Start form several
> > > providers. So cleaning the cache at every launch is not a solution. Is
> > > there any recommendations for having multiple repositories with identical
> > > bundles?
> > Not sure I totally understand your desire. You cannot install the same
> > bundle more than once, even if the location URL changes (technically, there
> > is a way to do this in the R4.3 spec, it is not really encouraged). If the
> > bundle is already installed, then there isn't much reason to install it
> > again, is there?
>
>
> Definitely not.
> > As I said, I'm not clear what you want to do. The issue isn't whether or
> > not your repositories have identical bundles, it is whether or not you want
> > to blindly install bundles even if they are duplicates.
>
>
> No, I do not want blindly install bundles.
> > The simple thing to do is to do is check the bundle exception from an
> > install to determine if it is due to a duplicate, if so, then you are fine
> > since the bundle is already installed.
> >
> > -> richard
> The problem was the bundle exception that is thrown when a bundle has a
> different location, because some codes after installBundle() was not
> executed. This code try to install a bundle fragment containing
> translations. It is now ok, I moved this code in a finally{}.
>
> It would better if the method context.installBundle() will return the
> bundle (without installing it) even when the location is different and
> log could generate a warning. In my case, I need information about the
> bundle to find its fragment.
If the install method gave back a handle for a Bundle object that was not an
actually installed bundle, then the lifecycle graph would need an additional
state. I don't think this is desirable.
If you need to inspect a bundle without installing it, you can always use the
java.util.jar.JarFile/JarInputStream API to read the manifest and entries.
Regards,
Neil
>
> Best,
>
> Nicolas
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> (mailto:[email protected])
> For additional commands, e-mail: [email protected]
> (mailto:[email protected])
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
