I'm experiencing this same problem (Wicket not loading the wicket.properties
due to the thread context classloader) with Wicket 1.3.1 in Equinox OSGi.
>From looking at Wicket's Application code, it appears that multiple
wicket.properties files can exist, and it will load them all. So, the
wicket.properties in wicket.jar should always be loaded as well as any other
wicket.properties that are application specific. This will work in a
traditional WAR file.
However, in OSGi, each bundle has its own classloader. So, if Wicket is in
its own bundle and my web application is in its own bundle, the current
implementation of Application will not work. Using only the thread context
classloader will not accomodate loading multiple wicket.properties.
Multiple classloaders must be checked.
I've put together and tested a modified Application.java which works in
OSGi. Would something like this be acceptable?
public final void initializeComponents()
{
// Load any wicket properties files we can find
try
{
Set loadedFiles = new HashSet();
// Load properties files used by all libraries
// Try the classloader for the wicket jar/bundle
Enumeration resources = Application.class.getClassLoader()
.getResources("wicket.properties");
loadResources(resources, loadedFiles);
// Try the classloader for the user's application jar/bundle
resources = getClass().getClassLoader()
.getResources("wicket.properties");
loadResources(resources, loadedFiles);
// Try the context class loader
resources = Thread.currentThread()
.getContextClassLoader()
.getResources("wicket.properties");
loadResources(resources, loadedFiles);
}
catch (IOException e)
{
throw new WicketRuntimeException("Unable to load
initializers file", e);
}
// now call any initializers we read
callInitializers();
}
private void loadResources(Enumeration resources, Set loadedFiles) throws
IOException
{
if (resources != null)
{
while (resources.hasMoreElements())
{
InputStream in = null;
try
{
final URL url = (URL)resources.nextElement();
if (!loadedFiles.contains(url))
{
log.info("resource url: {} ",
url);
final Properties properties = new
Properties();
in = url.openStream();
properties.load(in);
load(properties);
loadedFiles.add(url);
}
}
finally
{
if (in != null)
{
in.close();
}
}
}
}
}
Al Maw wrote:
>
> Jan Vermeulen wrote:
>> 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 ?
>
> Yes, it will always be packaged in the Wicket JAR file, at any rate.
> What this means in an OSGI environment I'm afraid I don't know. ;-)
>
>> 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.
>>
>
> Yep, absolutely. I've updated it to use the Thread's contextClassLoader,
> which I think should be sufficient, no?
>
> Al
>
>
--
View this message in context:
http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tp11194510p15642235.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
