Handle potential bundle:// protocol with VFS

[alesj]

WRT https://jira.jboss.org/jira/browse/JBOSGI-201

"alesj" wrote:

We should be able to handle bundle:// protocol.

e.g. bundle://<bundle_id>/<resource_path>

"thomas" wrote:

Could you perhaps give a use case for this functionality?

"alesj" wrote:

Instead of sharing resources among bundles with full resource path,
you can simply reference bundles directly (currently via id), hence hiding the details.

"dml" wrote:

However this is done, it shouldn't use the host name field (recall the problems with vfsmemory URLs). Personally I think the best solution would be to have a global VFS location where bundles can be found by ID, e.g. file:///osgi/bundles/by-id/[id]/[path] in VFS3 or the equivalent in VFS2.

"thomas" wrote:

Resources could be shared by the bundle root VirtualFile, no?

[alesj]

e.g. Felix uses this pattern

bundle://<bundle-id>.<bundle-revision>:<bundle-class-path-index>/path/to/resource

Where actually it should be

bundle://<framework-id>.<bundle-id>.<revision>:<index>/path/to/resource

"richardh" wrote:

This is still an issue if you have multiple frameworks in the same process independently.
The framework needs to multiplex the URL stream handler factory.
So, that multiplexer needs to know the framework ID.

[alesj]

"dml" wrote:

However this is done, it shouldn't use the host name field (recall the problems with vfsmemory URLs).

What was the vfsmemory problem again?
Or what do you suggest - apart from the below idea?

"dml" wrote:

Personally I think the best solution would be to have a global VFS location where bundles can be found by ID, e.g. file:///osgi/bundles/by-id/[id]/[path] in VFS3 or the equivalent in VFS2.

I don't think we should abuse file protocol too much.

"thomas" wrote:

Resources could be shared by the bundle root VirtualFile, no?

Sure, but like I said, that's too specific detail.
For some internal - cross-bundle - communication we should use bundles (actually its ids),
and leave the impl details to framework.

e.g. although this is not standard, osgi devs do use it quite a lot to find resources across bundles

[dmlloyd]

"alesj" wrote:

"dml" wrote:

However this is done, it shouldn't use the host name field (recall the problems with vfsmemory URLs).

What was the vfsmemory problem again?
Or what do you suggest - apart from the below idea?

The problem was that the uuid in the host name field isn't a valid host name, so things that expect it to be one failed when they tried to do DNS lookups and so forth. This is the real abuse - the lesson is that for URLs, the host name field should only contain a host name, and the port field should only contain a port. If there is no host name or port, then the URL scheme-specific part should start with "///" and any additional data should be contained afterwards. Or, use a URI instead.

"alesj" wrote:

"dml" wrote:

Personally I think the best solution would be to have a global VFS location where bundles can be found by ID, e.g. file:///osgi/bundles/by-id/[id]/[path] in VFS3 or the equivalent in VFS2.

I don't think we should abuse file protocol too much.

It's not an abuse, it's in line with the design (well, of VFS3 anyway). Also, using file: has the advantage of working with the default security manager policy parser without having to add yet more handler stubs to the boot classpath.

I think there's a lot of power to be had by mounting OSGi bundles in a consistent file-based scheme for VFS3. It would make finding resources a snap, and it could potentially simplify bundle classloaders as well. Basically it solves all the problems that bundle: does, and it has additional benefits besides. Seems like a perfect fit to me.

[thomas.diesler]

although this is not standard, osgi devs do use it quite a lot to find resources across bundles

Accessing a resources across bundles, you could do

sysContext.getBundle(someId).getResource("/some-resource.txt")

The return could be a VFS URL. I still don't quite understand the benefit of introducing/using an alternative URL representation.

Do you have a specific use case in mind, that you could present here?

[alesj]

Accessing a resources across bundles, you could do

sysContext.getBundle(someId).getResource("/some-resource.txt")

The return could be a VFS URL. I still don't quite understand the benefit of introducing/using an alternative URL representation.

Do you have a specific use case in mind, that you could present here?

1) You're using code, not URL or plain string. Users != no OSGi api
2) With direct VFS usage, you're by-passing restrictions enforced by bundles

With bundle:// approach, we handle both cases properly.

[thomas.diesler]

Sorry, I still don't get it. Anybody can do

InputStream is = sysContext.getBundle(someId).getResource("/some-resource.txt").openStream()

The format of the url would be irrelevant in that case. What is the use case where the URL format actually matters?

[alesj]

Anybody can do

InputStream is = sysContext.getBundle(someId).getResource("/some-resource.txt").openStream()

No.
e.g.
* I don't have access to system bundle / context -- remember your KernelLocator hack ;-)
* I don't wanna depend on OSGi api -- my code is 100% portable

What is the use case where the URL format actually matters?

OK, you could use direct vfsx protocol, but then, like I already said, you're by-passing bundle's restrictions.
Instead you pass around bundle protocol based url, knowing the restrictions apply.

User could still of course do direct access, but the framework shouldn't encourage him to do so,
hence a custom protocol that works more closely with the framework.

Currently this is a simple prototype, but I guess this could/will come in handy when you need
to pass resource access around to other pieces of the OSGi env; e.g. compendium, your interceptors, ...

[thomas.diesler]

you're by-passing bundle's restrictions.
Instead you pass around bundle protocol based url, knowing the restrictions apply.

This is a good point. Thanks.