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]

Reply via email to