The Holy Java

Building the right thing, building it right, fast

Posts Tagged ‘classpath’

Ivy resolve downloads but ignores some artifacts (though not modules)

Posted by Jakub Holý on December 23, 2010

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.

Read the rest of this entry »

Posted in Tools | Tagged: , , | Comments Off

Troubleshooting Class/Resource Loading on an Application Server

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 (ClassLoader.getSystemResource).

Update 08/11/06:  You can now get the ClassLoaderViewer.jsp from

Posted in j2ee, Languages | Tagged: , , , | Comments Off

Eclipse: Run => NoClassDefFoundError for an interface when loading a class implementing it

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)
    at java.lang.ClassLoader.findBootstrapClass0(
    at java.lang.ClassLoader.loadClass(
    at java.lang.ClassLoader.loadClass(
    at sun.misc.Launcher$AppClassLoader.loadClass(
    at java.lang.ClassLoader.loadClass(

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.

Posted in Languages | Tagged: , | Comments Off