cailin186 / reflections

Automatically exported from code.google.com/p/reflections
Do What The F*ck You Want To Public License
0 stars 0 forks source link

Reflections can't find class specified in embedded classpath entry of executable jar #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
If reflections encounters an executable jar with a classpath entry embedded in 
the manifest, it 
can't find classes pointed to by that classpath manifest entry.

What steps will reproduce the problem?
1) Open the attached sample.
2) Run ant, altering / overriding the parameter lib.dir to point to your 
external dependencies.
3) Run the sample using java -jar ClassFinder.jar.
4) Edit the build.xml to move TestImpl.class into ClassFinder.jar.
5) Rerun the sample using java -jar ClassFinder.jar.
6) Reflections can now find the jar.

What is the expected output? What do you see instead?
Expected:
Reflections found class: TestImpl
Success finding TestImpl class on classpath

Actual:
Unable to find class using reflections
Success finding TestImpl class on classpath

What version of the product are you using? On what operating system?
0.9.5-RC1 on SuSE Linux.

Please provide any additional information below.

Original issue reported on code.google.com by mha...@gmail.com on 13 Apr 2010 at 9:42

Attachments:

GoogleCodeExporter commented 9 years ago
I think I have the same issue.
I use fat-jar to package a standalone JAR.
The reflection works well when running in eclipse, but not with the standlone 
JAR.
The reflections framework says :

[main] ERROR org.reflections.Reflections - given scan urls are empty. set urls 
in the configuration

And indeed, when I trace the return of :
ClasspathHelper.getUrlsForPackagePrefix(<MY_PACKAGE>);

It is empty.

Any help would be appreciated.

Brgds,
Raphael

Original comment by raphael....@gmail.com on 1 Jul 2010 at 8:26

GoogleCodeExporter commented 9 years ago
I believe the problem is in ClasspathHelper.tryToGetValidUrl(...)

the line:

            if (new File(filename).exists())

filename is from a URL, so it has a "scheme" as a prefix, like 
"file:/my/path/to.jar".  new File(filname).exists() == false because of the 
"file:" prefix.

Original comment by btoddb on 16 Nov 2010 at 5:58

GoogleCodeExporter commented 9 years ago
This can also be a problem when testing Reflections in a Maven build using the 
Surefire plugin. By default, the plugin creates a manifest-only JAR as 
described in [1]. That page also suggests a couple of possible workarounds, the 
first of which is to set

useSystemClassLoader=false (which causes Surefire to use an isolated 
classloader)

and, if that doesn't work, to set

useManifestOnlyJar=false (which results in a "plain old classpath" but may 
violate system command line length limits).

[1] 
http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.htm
l

Original comment by sharedo...@gmail.com on 5 Dec 2010 at 7:47

GoogleCodeExporter commented 9 years ago
fixed on trunk

Original comment by ronm...@gmail.com on 12 May 2011 at 8:28

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I still have the problem in the version 0.9.6, not fixed :(

Reflections reflections = new Reflections("mypackage");
Set<Class<T>> annotatedClasses = (Set<Class<T>>) (Object) 
reflections.getTypesAnnotatedWith(annotationClass);

the set is empty

I run the class under eclipse or maven, and its failing.

10:00:15-586 ERROR: org.reflections.Reflections::given scan urls are empty. set 
urls in the configuration

OS: windows 7
java: JDK6
maven: 3.0.3
eclipse : indigo

Original comment by regis.le...@gmail.com on 27 Feb 2012 at 3:22

GoogleCodeExporter commented 9 years ago
What is weird it is not failing under linux. Ubuntu

Original comment by regis.le...@gmail.com on 27 Feb 2012 at 3:22

GoogleCodeExporter commented 9 years ago
Having the same problem here - reflections 0.9.6, guava 10.0.1, Windows 7 x64 
JDK 1.6.0_29.

Original comment by floz...@gmail.com on 26 Mar 2012 at 7:36

GoogleCodeExporter commented 9 years ago
Issue 101 has the right fix attached. Please apply !

Original comment by Julien.N...@gmail.com on 3 Apr 2012 at 12:19

GoogleCodeExporter commented 9 years ago
I'm having the same problem in the version 0.9.8. However I'm using CentOS 6.

Original comment by gabriel...@gmail.com on 14 Aug 2012 at 9:05

GoogleCodeExporter commented 9 years ago
If your using an option (e.g. in eclipse) to package the library jars within 
the executable jar, eclipse will also package it's own classloader to provide 
jar-in-jar loading. But that will confuse Reflection. Try the "extract 
libraries to generated jar" option or "copy to sub-folder". This should work.

Original comment by caend...@googlemail.com on 24 Apr 2013 at 6:18

GoogleCodeExporter commented 9 years ago
Thanks very much for the suggestion to try extracting libraries rather than 
packaging them. I have spent hours trying to find a fix for this problem, and 
that solved it.

Original comment by james.c....@gmail.com on 14 Oct 2013 at 12:29