I did some new experiments, and I know what is the problem:
The classloader only finds the 'wicket.properties' file, when it's in the
classpath of that classloader. And the classloader used here is:
Application.initializeComponents() {
...
... getClass().getClassLoader()
...
}
So if one has implemented his subClass of Application, it will use the
classloader of that class, which will be normally the classloader of the
webapplication.
Now, if you use Wicket in an OSGI environment, most likely the Wicket
classes (and thus the 'wicket.properties' file) will be in another bundle,
on which your webapplication bundle depends. And each bundle has its own
classloader. So the 'wicket.properties' file has now become invisible.
I made the following small change to the code:
Application.initializeComponents() {
...
... Application.class.getClassLoader()
...
}
And then everything seems to work, because now we're using the classloader
of the bundle in which resides 'org.apache.wicket.Application'.
So my question is now: is that 'wicket.properties' file meant to be a
resource that's always within the Wicket 'bundle' ? If so, would it not be
better to use the latter code to lookup resources, so that it works in
environments with multiple classloaders ?
And if it's not that evident where the 'wicket.properties' file should
reside, don't you need some utility method for resource loading that tries
out different classloaders ? Something like:
public static URL loadResource(String path) throws
ClassNotFoundException {
try {
return
(Thread.currentThread().getContextClassLoader().getResource(path));
} catch (ClassNotFoundException e) {
return (getClass().getClassLoader().getResource(path));
}
}
Jan.
--
View this message in context:
http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11209399
Sent from the Wicket - Dev mailing list archive at Nabble.com.
