On 2/9/12 13: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.
Yes, it doesn't do that. You can determine if it is a duplicate by
catching the exception from installBundle and checking the exception
type (see the spec). The difficulty is that there is no way at this
point to know which installed bundle is the duplicate. I think the only
option is to try to read the Bundle-SymbolicName manifest header out of
the bundle that failed, then you can use that to find the already
installed bundle.
It's a pain and not very well thought out.
-> richard
Best,
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]