I thought we also had a method on the application class
(getClassResolver or something like that) that is there for special
class loading
On 2/23/08, Adam Harris <[EMAIL PROTECTED]> wrote:
>
> 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.
>
>
