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.
> >
> >
>
