currentThread, getContextClassLoader and get resource

[Gleb]

I've got a strange situation.
I have third-party jar file which classes I am using in my app. The
used class has
URL url = Thread.currentThread().getContextClassLoader().getResource("config.xml");
in one of its method.

When I run my app application compilied in class-files everything is
allright, but when I put it in jar-file url becomes null. Jar-file
contains my classes and all third-party classes plus config.xml in the
root of jar-file. The most strange thing is that when I run
URL url = Thread.currentThread().getContextClassLoader().getResource("config.xml");
from the mthod of my class config.xml is available. So basically
config.xml is richable from my class but not from hird-party class
withing one jar-file. I've tried to put config.xml into different
directories withing jar-file without success.
Could be any particular detailes about this third-party class
implementation? Or any reason why ContextClassLoader behaves
differently in my class and third-party class? I really don't have any
ideas any more .

 

[Oscar kind]

When I run my app application compilied in class-files everything is
allright, but when I put it in jar-file url becomes null. Jar-file
contains my classes and all third-party classes plus config.xml in the
root of jar-file. The most strange thing is that when I run
URL url = Thread.currentThread().getContextClassLoader().getResource("config.xml");
from the mthod of my class config.xml is available. So basically
config.xml is richable from my class but not from hird-party class
withing one jar-file. I've tried to put config.xml into different
directories withing jar-file without success.
Could be any particular detailes about this third-party class
implementation? Or any reason why ContextClassLoader behaves
differently in my class and third-party class? I really don't have any
ideas any more .

AFAIK, this is a classloader issue. At leats it sounds that way. This is
what I think is happening:

When you're using class files directly, there is only one classloader for
all files. Thus the config.txt is available from the library.

When you package the stuff, your classloader has a complete path, but each
library has its own classloader. Thus the library cannot find config.txt
anymore, because that classloader cannot find it.


If my assessment of the situation is correct (I'm not entirely certain),
then it's a design flaw in the library.

You could solve this by adding "." to the Class-Path header in the
manifest of the library jar file, and place config.txt in the current
directory.

Is possible however, a better solution would be to add a configuration
method to the library that takes a Properties object instead of reading a
configuration file.

 

[PerfectDayToChaseTornados]

| I've got a strange situation.
| I have third-party jar file which classes I am using in my app. The
| used class has
| URL url =
Thread.currentThread().getContextClassLoader().getResource("config.xml");
| in one of its method.
|
| When I run my app application compilied in class-files everything is
| allright, but when I put it in jar-file url becomes null. Jar-file
| contains my classes and all third-party classes plus config.xml in the
| root of jar-file. The most strange thing is that when I run
| URL url =
Thread.currentThread().getContextClassLoader().getResource("config.xml");
| from the mthod of my class config.xml is available. So basically
| config.xml is richable from my class but not from hird-party class
| withing one jar-file. I've tried to put config.xml into different
| directories withing jar-file without success.
| Could be any particular detailes about this third-party class
| implementation? Or any reason why ContextClassLoader behaves
| differently in my class and third-party class? I really don't have any
| ideas any more .

This excellent paper on classloaders will help you understand what is going
on here
http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf

--
-P
"Programs that are hard to read are hard to modify.
Programs that have duplicated logic are hard to modify.
Programs with complex conditional logic are hard to modify"

( Kent Beck)