On 6/20/12 10:40 , Dan Gravell wrote:
On Wed, Jun 20, 2012 at 3:33 PM, Richard S. Hall <[email protected]>wrote:
On 6/20/12 10:20 , Dan Gravell wrote:
That's ok - I know we are using Felix. And this worked before I used OBR,
because bundle.getLocation would return a file URL. However the OBR URL
returned by getLocation is totally abstracted. How might I find the
location in the bundle cache?
Just to be clear, we are talking about two different locations:
1. The bundle.getLocation() method was returning the original location
from which the framework made a copy of the bundle to install into
its bundle cache.
2. The bundle in the bundle cache is the copy made from the original
location above.
So, in your old solution you were getting it from the source. Now you will
be getting it from the copy.
Hmmm, interesting. So it sounds like updating that bundle (from a different
source) wouldn't work because it would just point back to the original
location. I thought I'd observed it work, but maybe my test wasn't
satisfactory...
Yes, that wouldn't work. The location never changes, so it will always
point to the original, not any subsequent updates.
Well, you can configure the location of the bundle cache using the
org.osgi.framework.storage property, so you can look up this property.
After that, then yes you'll need to know the structure of the cache to find
the bundle you want. You shouldn't need to read any of the files, though,
you just need to know the structure so you can find what you want.
Of course! I forgot about the property. I thought I would need to read
bundle.info though so I can find out which bundle ("bundle0" - "bundleNN")
is the one I want to return the location for.
Technically, you could. But the N in "bundleN" is the bundle ID, so it
is pretty straightforward to determine which bundle ID you want. The
main trick is that the "versionX.Y" directory that contains the bundle
JAR file will change after an update (make sure you refresh too). So,
you have to just look for the "version" prefix and largely ignore the X.Y...
-> richard
You could hide all of this behind some method, but it is still ugly...
Agreed!
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
