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/
