i just did the last thing (added Iterator getResources(String name)) to the IClassResolver interface
Didnt rename anything or what ever because that would really break stuff i guess (now only implementors of that interface do break) Didnt commit it yet just created a patch that people can test: https://issues.apache.org/jira/browse/WICKET-1371 On Sat, Feb 23, 2008 at 4:17 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > we have > > public interface IClassResolver > { > Class resolveClass(final String classname) throws > ClassNotFoundException; > } > > i guess we can also add an accompanying IClasspathResourceResolver to > keep it a bit more in sync... > > or maybe rename IClassResolver into something else and add the > resolveResource() to that... > > -igor > > > On Fri, Feb 22, 2008 at 6:18 PM, Johan Compagner <[EMAIL PROTECTED]> > wrote: > > 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<http://nabble.com/> > . > > > > > > > > >
