"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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...