reflect.Classpath should provide ResourceInfo in addition to ClassInfo

[GoogleCodeExporter]

The Classpath class being added to 14.0 should provide methods for access not 
only to classes but also general resources on the classpath.

Original issue reported on code.google.com by kaspe...@gmail.com on 29 Nov 2012 at 9:33

[GoogleCodeExporter]

Can you add some details about the use case where this is useful?

Original comment by be...@google.com on 5 Jan 2013 at 2:03

[GoogleCodeExporter]

It would be really nice, if you could specify a file pattern such as
give me all /WEB-INF/security*.xml files that are on the class path.

See also these questions on stackoverflow

http://stackoverflow.com/questions/9802785/find-all-resource-with-specific-exten
sion-from-jar-programmatically

http://stackoverflow.com/questions/13183248/java-web-start-enumerate-all-files-o
f-certain-type-from-resources

Original comment by kaspe...@gmail.com on 5 Jan 2013 at 12:04

[GoogleCodeExporter]

Oh that makes sense. Thanks!

Original comment by be...@google.com on 7 Jan 2013 at 11:52

[GoogleCodeExporter]

Oh. And after getting the list of security.xml, they will be applied to the web 
application as security checks?

My only concern is with the current implementation of ClassPath, and the use of 
it in production code. 

ClassPath is tested internally in Google environment but not extensively on all 
application servers in the wild. In fact, there is no guaranteed portable way 
to browse classes/resources on the class path, in theory.

If for example, one deployment environment doesn't use URLClassLoader but 
re-invent its own ClassLoader, ClassPath may not find classes or resources 
meant to be found. And that means the app may silently lose security protection 
unnoticed.

Currently we use ClassPath mostly for testing and other non-mission-critical 
area and so far enumerating resources hasn't come up yet.

Original comment by be...@google.com on 8 Jan 2013 at 2:39

[GoogleCodeExporter]

Right, my example was pretty bad I think.
Like the SO links. I do not really have a need for it to work in various 
application servers.
I just want a best-effort approach without to much magic.

Right now I have a dependency on Spring just for getting the resources out of 
my application jar.
ApplicationContext context = new ClassPathXmlApplicationContext();
Resource[] resources = context.getResources("classpath:/" + folder + "/*.*");

Original comment by kaspe...@gmail.com on 8 Jan 2013 at 8:20

[GoogleCodeExporter]

Original comment by be...@google.com on 11 Jan 2013 at 2:13

• Changed state: Accepted

[GoogleCodeExporter]

Issue 1247 has been merged into this issue.

Original comment by be...@google.com on 11 Jan 2013 at 4:27

[GoogleCodeExporter]

http://code.google.com/p/guava-libraries/source/detail?r=28f3cd2759061207c89c25a
2635154c3adaabc2b

Original comment by cpov...@google.com on 11 Jan 2013 at 5:11

• Changed state: Fixed
• Added labels: Milestone-Release14, Package-Reflect, Type-Addition

[GoogleCodeExporter]

I was trying out the implementation. And it is a bit too slow for my liking. At 
least compared to what I have using Spring right now.

ClassPath.from(SomeClass.class.getClassLoader()).getResources() returns a set 
with around 20.000 items for a project of mine. Mainly because it includes all 
of the JDK classes.

In Spring I would do something like this
Resource[] xmlResources = context.getResources("classpath:/images/*.*"); just 
getting what I need.

I really think ClassPath.from(ClassLoader) should lazy load information, for 
example, like Java's own ServiceLoader. And then provide search operations that 
do not have to process every file on the classpath.

Original comment by kaspe...@gmail.com on 4 Feb 2013 at 11:40

[GoogleCodeExporter]

ClassPath.from() is designed so that it's called only once and the returned 
ClassPath object can be saved to be queried later.

Though do you have the time it took for ClassPath and Spring getResources() to 
run?

Uless you are running with class files in file system, both implementations 
scan every jar files.

ClassPath copies the result into an ImmutableSet, while Spring filters the 
scanned entries right away. So I can see Spring implementation being more 
memory efficient but they appear to pay the same IO cost.

Original comment by be...@google.com on 4 Feb 2013 at 3:07

[GoogleCodeExporter]

Original comment by be...@google.com on 4 Feb 2013 at 3:30

• Changed state: Research

[GoogleCodeExporter]

Here's what Spring does:

Given a pattern com/mycomp/*, it first gets all the resource urls for the 
directory resource "com/mycomp", which are typically contained in jar files. It 
then scans these jar files only, assuming that any jar file containing a 
"com/mycomp/something" must also contain the directory resource "com/mycomp/". 

But I have failed to find specification to warrant this assumption. It's a 
tempting optimization but would be nice if we can find it's a safe assumption.

Original comment by be...@google.com on 6 Feb 2013 at 5:58

[GoogleCodeExporter]

Manually running jar cvf proves not adding the directory resources along with 
the class files. So this approach isn't always reliable.

Original comment by be...@google.com on 7 Feb 2013 at 3:38

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit