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