[jboss-dev-forums] [JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

[david.lloyd@jboss.com]

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

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265108#4265108

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265108