This content has been marked as final.
Show 8 replies
-
1. Re: Handle potential bundle:// protocol with VFS
alesj Nov 10, 2009 6:31 PM (in response to alesj)e.g. Felix uses this pattern
bundle://<bundle-id>.<bundle-revision>:<bundle-class-path-index>/path/to/resource
Where actually it should bebundle://<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. -
2. Re: Handle potential bundle:// protocol with VFS
alesj Nov 11, 2009 12:02 PM (in response to 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 -
3. Re: Handle potential bundle:// protocol with VFS
dmlloyd Nov 11, 2009 12:11 PM (in response to alesj)"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. -
4. Re: Handle potential bundle:// protocol with VFS
thomas.diesler Nov 11, 2009 12:11 PM (in response to alesj)
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 dosysContext.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? -
5. Re: Handle potential bundle:// protocol with VFS
alesj Nov 11, 2009 12:23 PM (in response to alesj)"thomas.diesler@jboss.com" wrote:
Accessing a resources across bundles, you could dosysContext.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. -
6. Re: Handle potential bundle:// protocol with VFS
thomas.diesler Nov 13, 2009 3:39 AM (in response to alesj)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? -
7. Re: Handle potential bundle:// protocol with VFS
alesj Nov 13, 2009 3:54 AM (in response to alesj)"thomas.diesler@jboss.com" wrote:
Anybody can doInputStream 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"thomas.diesler@jboss.com" wrote:
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, ... -
8. Re: Handle potential bundle:// protocol with VFS
thomas.diesler Nov 16, 2009 2:27 AM (in response to alesj)
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.