You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2005/08/02 22:17:17 UTC
Re: [vfs] res: protocol issue (possible enhancement?)
Hi!
> I tried using the res: protocol and it worked great until I put the
> same named package in the classpath before the one I had resources
> in. For instance, I have...
I simply use the getClass().getClassLoader().getResource() - so this is
the JVM behaviour.
I understand your needs and we could implement it by traversing the
classpath, but I wont do it for the 1.0 release - sorry - its too much
work for now.
Maybe a patch could speed thinks *hint hint* ;-)
---
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 (possible enhancement?)
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Mario Ivankovits <ma...@ops.co.at>:
> Jacob Kjome wrote:
> > FileSystemManager fsManager = VFS.getManager();
> > FileObject pkg = fsManager.resolveFile( "res:com/mycompany/mypackage" );
> >
> > And my classpath looked like the following (with both "com" in the
> > current directory and that same package in my.jar)...
> >
> > .;my.jar
> >
> > I'd need the FileObject to represent multiple paths so when I can
> > pkg.getChildren(), it represents resources from both package paths,
> > not just the first one it finds, which is the current case with the
> > "res" scheme. Is there an existing example FileObject impl that
> > represents multiple paths? If not, how would I go about this? I just
> > need a little direction.
> Oh yes, thats a problem.
> One solution could be to create a CompositeFileObject. This hold
> multiple FileObjects and merges all outputs (getChildren, findFiles, ...)
>
I thought about that, but I've a bit confused. I would have expected the "pkg"
FileObject to be a UrlFileObject, but it was a LocalFile (shouldn't this be
LocalFileObject, BTW?). That's based on the ResourceFileSystemConfigBuilder
defining its config class as UrlFileSystem.class.
I'm also a bit confused at how the ResourceFileProvider.findFile() makes this
call...
FileObject fo =
getContext().getFileSystemManager().resolveFile(url.toExternalForm());
But if you look at DefaultFileSystemManager.resolveFile(), it seems to simply
call the provider's findFile() method...
// Extract the scheme
final String scheme = UriParser.extractScheme(uri);
if (scheme != null)
{
// An absolute URI - locate the provider
final FileProvider provider = (FileProvider) providers.get(scheme);
if (provider != null)
{
return provider.findFile(baseFile, uri, fileSystemOptions);
}
How is this not circular? I must be missing something. Are there any docs that
describe the design of VFS rather than just how to use it?
> But there are a couple of problems, e.g. what if a entry is a file in
> one jar and a directory in another? What should the CompositeFileObject
> say when using getType() then?
>
I find that to be an unlikely circumstance. However, in that case we can either
throw an exception or treat it as a directory if at least one of the resources
is a directory and return any that aren't directories in the getChildren().
Jake
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
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 (possible enhancement?)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Jacob Kjome wrote:
> FileSystemManager fsManager = VFS.getManager();
> FileObject pkg = fsManager.resolveFile( "res:com/mycompany/mypackage" );
>
> And my classpath looked like the following (with both "com" in the
> current directory and that same package in my.jar)...
>
> .;my.jar
>
> I'd need the FileObject to represent multiple paths so when I can
> pkg.getChildren(), it represents resources from both package paths,
> not just the first one it finds, which is the current case with the
> "res" scheme. Is there an existing example FileObject impl that
> represents multiple paths? If not, how would I go about this? I just
> need a little direction.
Oh yes, thats a problem.
One solution could be to create a CompositeFileObject. This hold
multiple FileObjects and merges all outputs (getChildren, findFiles, ...)
But there are a couple of problems, e.g. what if a entry is a file in
one jar and a directory in another? What should the CompositeFileObject
say when using getType() then?
---
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 (possible enhancement?)
Posted by Jacob Kjome <ho...@visi.com>.
Hi Mario,
I'm a little lost on how to implement this. I can't just have something
like a ClasspathFileProvider extending ResourceFileProvider and overriding
findFile(), because that only allows for a single base path. For instance,
if I had...
FileSystemManager fsManager = VFS.getManager();
FileObject pkg = fsManager.resolveFile( "res:com/mycompany/mypackage" );
And my classpath looked like the following (with both "com" in the current
directory and that same package in my.jar)...
.;my.jar
I'd need the FileObject to represent multiple paths so when I can
pkg.getChildren(), it represents resources from both package paths, not
just the first one it finds, which is the current case with the "res"
scheme. Is there an existing example FileObject impl that represents
multiple paths? If not, how would I go about this? I just need a little
direction.
thanks,
Jake
At 09:33 AM 8/3/2005 -0500, you wrote:
>Quoting Mario Ivankovits <ma...@ops.co.at>:
>
>> Jacob Kjome wrote:
>> > It looks like the only special characters allowed in the scheme are
>> > '+', '-', and '.'. I guess that means my proposed "res*:" protocol is
>> > out. Is there a reason that only the said special characters are
>> > allowed and not others? Would '*' be ok to add to that list? Or is
>> > there a URL standard that you are following here that limits the
>> > characters to what has already been specified? If '*' isn't allowed,
>> > would it be ok to use "res+:"?
>> What if we simply name it "classpath:"?
>>
>> So "res:" uses the default JVM rules and "classpath:" scans the whole
>> classpath.
>>
>
>That probably makes sense. I'll try to look into this tonight.
>
>Jake
>
>>
>> ---
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
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 (possible enhancement?)
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Mario Ivankovits <ma...@ops.co.at>:
> Jacob Kjome wrote:
> > It looks like the only special characters allowed in the scheme are
> > '+', '-', and '.'. I guess that means my proposed "res*:" protocol is
> > out. Is there a reason that only the said special characters are
> > allowed and not others? Would '*' be ok to add to that list? Or is
> > there a URL standard that you are following here that limits the
> > characters to what has already been specified? If '*' isn't allowed,
> > would it be ok to use "res+:"?
> What if we simply name it "classpath:"?
>
> So "res:" uses the default JVM rules and "classpath:" scans the whole
> classpath.
>
That probably makes sense. I'll try to look into this tonight.
Jake
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
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 (possible enhancement?)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Jacob Kjome wrote:
> It looks like the only special characters allowed in the scheme are
> '+', '-', and '.'. I guess that means my proposed "res*:" protocol is
> out. Is there a reason that only the said special characters are
> allowed and not others? Would '*' be ok to add to that list? Or is
> there a URL standard that you are following here that limits the
> characters to what has already been specified? If '*' isn't allowed,
> would it be ok to use "res+:"?
What if we simply name it "classpath:"?
So "res:" uses the default JVM rules and "classpath:" scans the whole
classpath.
---
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 (possible enhancement?)
Posted by Jacob Kjome <ho...@visi.com>.
At 10:17 PM 8/2/2005 +0200, you wrote:
>Hi!
>> I tried using the res: protocol and it worked great until I put the
>> same named package in the classpath before the one I had resources
>> in. For instance, I have...
>I simply use the getClass().getClassLoader().getResource() - so this is
>the JVM behaviour.
>
>I understand your needs and we could implement it by traversing the
>classpath, but I wont do it for the 1.0 release - sorry - its too much
>work for now.
>Maybe a patch could speed thinks *hint hint* ;-)
>
I'll see if I can get to it sometime tomorrow. So far I looked at the
allowed characters in a scheme. I found UriParser.extractScheme(uri,
buffer) which has the following code...
if (pos > 0
&& ((ch >= '0' && ch <= '9')
|| ch == '+' || ch == '-' || ch == '.'))
{
// A scheme character (these are not allowed as the first
// character of the scheme, but can be used as subsequent
// characters.
continue;
}
It looks like the only special characters allowed in the scheme are '+',
'-', and '.'. I guess that means my proposed "res*:" protocol is out. Is
there a reason that only the said special characters are allowed and not
others? Would '*' be ok to add to that list? Or is there a URL standard
that you are following here that limits the characters to what has already
been specified? If '*' isn't allowed, would it be ok to use "res+:"?
Jake
>
>---
>Mario
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org