[VFS] "res:" protocol issue

[Philippe Poulard <Ph...@sophia.inria.fr>]

hi,

i'm thinking about solutions on multiple matchings with the "res:" protocol

in fact, as a file is unique in its context (a resolution must always 
give 0 or 1 real file), there are no direct solution that VFS can provide

the problem is the same with the "file:" scheme, for Windows that has 
multiple drives :
file:///path/to/resource
could give several resources if each drive is considered

what are the solution ?
1) if no additional information is given, a "current" drive, say "C:" is 
assumed, and the resolution gives a single result ; that's the same for 
the "res:" scheme : there is a mechanism that gives a single result 
(arbitrary, it is the first found, which is not a bad strategy, i don't 
know a better one)

2) if the drive is known, it is simply specified :
file://C:/path/to/resource
        ^^ here
now, it's the same with "res:", that can be replaced by "jar:"
jar:this.jar!/path/to/resource

in fact, there is still a difference between "res:" and "jar:" : "res:" 
gives what is in the classpath, "jar:" gives any jar (and i don't know 
if a class taken from an explicit "jar:" that has been also specified in 
the classpath should be load by the same classloader, that is to say : 
are they the same class ? is there a Java expert here ?)

now what's happenned if you don't know the drives ? just ask for it :
File.listRoots();
now you can resolve /path/to/resource on each drive and select those 
that you prefer

this is just what is missing for "res:"
ResUtil.listJar();
now you can resolve /path/to/resource on each jar and select those that 
you prefer

just write the tool
-- 
Cordialement,

            ///
           (. .)
  -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
  -----------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [VFS] "res:" protocol issue

[Mario Ivankovits <ma...@ops.co.at>]

For sure we can combine both methods to:

FileObject fo = new CompositeFileObject(ResUtils.resolveClasspath())

Which is exactly what the classpath:/ fileprovider will have to do at first.

---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [VFS] "res:" protocol issue

[Mario Ivankovits <ma...@ops.co.at>]

Hi (again ;-) )!
> this is just what is missing for "res:"
> ResUtil.listJar();
> now you can resolve /path/to/resource on each jar and select those 
> that you prefer
>
> just write the tool
And if you ;-) write it dont forget a classpath do not only contain jars 
but also directories.

So if I understand what you would like to have is something like

FileObject[] fos = ResUtils.resolveClasspath();

and then one is able to check if a requested resource is child of one of 
the "fos".


I have hade something else in mind, I thought it would be nice if we 
introduce a CompositeFileObject then we can do:

FileObject fo = VFS.getManager().resovleFile("classpath:org/");
FileObject[] fos = fo.getChildren();

The returned array is then a list of (maybe Composite-) FileObjects 
collected through different jars/directories.

The problem is that "org" in one jar can be a "file" and in another a 
"directory", but this can be solved in CompositeFileObject and so there 
is no "unclean" solution in VFS core.

This "CompositeFileObject" can be used outside of classpath:// to, e.g. 
what you can do is

FileObject fo = new CompositeFileObject("file://c:/", "file://d:/");
A fo.getChildren() will return a list from both filesystems then.


BTW: Notice the trailing "/" ;-) I start to like it.

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org