Guillaume Nodet wrote:
The "bundle:" protocol URL handler is built in Felix framework, but
does not seem to work well for me at the moment. The idea behing this
URL handler is to be able to access any resource inside a bundle. The
syntax is as following:
bundle://[bundleId].[bundleRev]:[classPathId]/[path]
where [bundleId] is the id of the bundle, [bundleRev] is the revision
of the bundle (when new versions are installed), [classPathId] is the
index in the list of jars that make the classpath (internal structure)
and [path] is the path of the resource in the bundle.
My problem is that [bundleRev] and [classPathId] refer to internal
structures and can't be accessed from outside the felix framework.
[classPathId] can be set to 0 to look inside the whole classpath
entries, but if not specified, the default value of the url port is -1
and an IndexOutOfBounds exception is thrown.
Yes, the exception sounds like a bug that should be fixed.
Another problem is that [bundleRev] can not be ommitted and (in
addition to the parsing having a bug) there is no default value.
Perhaps we should just define the default value to be the current revision.
I will raise a JIRA and attach a patch to do the following:
* if the url port is ommitted (thus defaults to -1), use the same
behavior as if 0 was used (search in the whole classpath)
ok
* fix the revision bundle parsing, which returns the bundle id if
none is specified: it will return -1 if the bundle revision was not
set
ok
* fix the look up mechanism so that when no bundle revision is
specified, (revision == -1), all bundle revisions will be searched in
reverse order (the most recent revision first)
Personally, I would just search the most recent and be done with it,
otherwise we could end up with situations where we are splitting across
revisions.
The last problem is really difficult to work around as there is no way
to find the bundle revision from a client bundle and there is no
default value, so the only way to make that work is to specify 0 and
expect the bundle to have not been updated (which ovbiously is not a
good idea).
While I agree that these are issues that should be addressed, we are
really talking about special cases here, since you generally shouldn't
be trying to construct your own bundle resource URL since the URL
structure is supposed to be opaque and framework dependent.
-> richard
Feedback welcome.
