I see. The IClassResolver mechanism seems like a nice approach to me;
presumably it wouldn't be hard to add a resolveResources() method to this?
We may do that to our own version of Wicket for the time being anyway. Any
idea how such a fix would fit into your plans for the 1.3 release?
Thanks,
Jan
On 23/08/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> what we have in wicket is a IClassResolver which we use to allow for
> pluggable class resolution. however what you are talking about is slightly
> different, it is about resolving resources on the classpath, and that
> needs
> a class loader.
>
> so i see a few options
>
> we can remove iclassresolver and instead allow users to set a classloader
> into application settings.
>
> we can add iclassresolver.resolveresources() and rename iclassresolver to
> something more appropriate
>
> just need to decide how to address it properly.
>
> -igor
>
>
>
>
> On 8/23/07, Jan Stette <[EMAIL PROTECTED]> wrote:
> >
> > Hi all,
> >
> > I've just started using Wicket, for a new project. In general it's
> > looking
> > very promising, but we've had one problem. We are using Wicket from
> > within
> > OSGi (Equinox). When we submit a Wicket servlet to our embedded web
> > server
> > (Jetty) and the servlet gets initialized, there is a
> NullPointerException
> > in
> > Application.initializeComponents(), on the following line:
> >
> > // Load properties files used by all libraries
> > final Enumeration resources = Thread.currentThread
> > ().getContextClassLoader()
> > .getResources("wicket.properties");
> >
> > The reason is that in the OSGi environment, there is no context
> > classloader
> > associated with the running thread. Making this assumption seems wrong
> to
> > me; something like the code in ClassLoaderResourceStreamLocator.javaseems
> > more appropriate.
> >
> > This is seen using Wicket 1.3 (latest beta), looking at the Wicket
> 1.2code,
> > it doesn't seem to have this problem.
> >
> > For the time being we can work around this by manually setting the
> current
> > thread's context classloader before activating the Wicket servlet, but
> it
> > doesn't seem to me that this should be necessary.
> >
> > I found a thread from last year discussing similar issues:
> >
> >
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg07325.html
> > .
> > (The original post in thread actually suggests changing *to* using the
> > current thread context classloader, which is wrong IMHO!) But later in
> > the
> > thread, providing a pluggable classloader access policy is
> discussed. Was
> > there a decision on how this should be done, or is this still an
> > outstanding
> > issue?
> >
> > Many thanks,
> > Jan
> >
>
