JIRA raised and patch attached: https://issues.apache.org/jira/browse/FELIX-577
On Fri, May 30, 2008 at 10:09 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <[EMAIL PROTECTED]> 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. >>> >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
