felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Problems with URL handler for bundle:// protocol
Date Fri, 30 May 2008 08:09:41 GMT
On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <heavy@ungoverned.org> wrote:
> 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.

Sounds good.

>> 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

Yeah, I agree this is felix dependant, but it's nonetheless really handy.
I suppose at some point, I would have to rewrite my own url handler to
handle this
in a less felix specific way.

>> Feedback welcome.

Guillaume Nodet
Blog: http://gnodet.blogspot.com/

View raw message