[vfs] res: protocol issue (possible enhancement?)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[vfs] res: protocol issue (possible enhancement?)

Jacob Kjome

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

CLASSPATH=.;mycompany-config.jar

directory looks like...

com/mycompany/config
mycompany-config.jar

My resources are in the jar file, but I have the same named package
external to the jar which comes before the jar in the classpath.  So, when
I do the following, I get no child FileObject output where I would if the
classpath entries were reversed...

FileSystemManager fsManager = VFS.getManager();
FileObject pkg = fsManager.resolveFile("res:com/mycompany/config");
FileObject[] children = pkg.getChildren();
System.out.println( "Children of " + pkg.getName().getURI() );
for ( int i = 0; i < children.length; i++ )
{
     System.out.println( children[ i ].getName() );
}

SpringFramework has similar functionality to VFS here, except that it
allows for a way to tell the program to look in all packages of the same
name on the classpath instead of stopping at the first one it finds.  It
goes something like this...

PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
    Resource[] resources =
resolver.getResources("classpath*:com/mycompany/config/*.xml");
    for (int i = 0; i < resources.length; i++) {
        Resource resource = resources[i];
        System.out.println(resource.getURL());
    }
}

Using this, I would actually get the resources in the jar file (as well as
any found outside the jar) because I used "classpath*:" instead of
"classpath:" (notice the "*" in the former) which would have produced the
same undesired behavior as I'm seeing in VFS.  I need the Spring-like
behavior because I can't always control the classpath, and even if I could
this would still be brittle because it would depend on careful
configuration of the classpath which is all but impossible in J2EE
environments.

So, am I missing something that VFS already supports or is this something
that would have to be added as an enhancement?  Seems like "res*:" would be
a good way to specify this, no?  Would it be possible to get this in before
the 1.0 final release?


Jake


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Jacob Kjome
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Jacob Kjome
Quoting Mario Ivankovits <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Jacob Kjome
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 <[hidden email]>:
 >
 >> 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: [hidden email]
 >> For additional commands, e-mail: [hidden email]
 >>
 >
 >
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: [hidden email]
 >For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] res: protocol issue (possible enhancement?)

Jacob Kjome
Quoting Mario Ivankovits <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]