I’ve had a strange issue with Apache Ivy‘s resolve task – it resolved and downloaded all my dependencies but didn’t put some of them to the classpath (via ivy:cachepath) and certainly wouldn’t copy them either (via ivy:retrieve). An indicia was that in the resolve report the number of “artifacts” was zero while the number of “modules” matched the number of the dependencies. The issue was caused by my defaultconfmapping=”*->compile” – it turned out that most modules, as interpreted by Ivy, produce their artifacts only for the configuration “master” and not for compile.
Posts Tagged ‘classpath’
Posted by Jakub Holý on December 23, 2010
Posted by Jakub Holý on January 25, 2007
If you need to find out where is a certain class loaded from or where a class has loaded a resource (typically a configuration file) from, you can use the JSP below – just put it to your web app and point a browser to it.
Note: The resource loading tracking assumes that the loading class uses
getClass().getResource – this doesn’t need to be always the case, it could also use the context class loader (
Thread.currentThread().getContextClassLoader()) or load it as a system resource (
Update 08/11/06: You can now get the ClassLoaderViewer.jsp from SF.net.
Posted by Jakub Holý on April 21, 2006
I had quite a hard time trying to run the following code in Eclipse (CollectionUserType implements UserType):
The problem was:
Exception in thread “main” java.lang.NoClassDefFoundError: net/sf/hibernate/UserType
at java.lang.ClassLoader.findBootstrapClass(Native Method)
The strange thing was that I could define instances of both UserType and CollectionUserType so it was clear that the classes are available. The evident conclusion was that CollectionUserType is loaded by a special classloader that doesn’t have access to UserType.
Examining closely the Run Configuration I’ve discovered the cause: the location of CollectionUserType was among the Bootstrap Entries while the location of UserType was among User Entries. And since the bootstrap class loader is above other class loaders in the class loader hierarchy, it has no access to classes loaded by the subordinate class loaders (including UserType) while vice versa it’s all right.<
So the solution was to move the entry from Bootstrap Entries to User Entries.