You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jan Stette <ja...@gmail.com> on 2007/08/23 19:22:11 UTC
Problem with classloader in Wicket Application class
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.2 code,
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/wicket-develop@lists.sourceforge.net/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
Re: Problem with classloader in Wicket Application class
Posted by Igor Vaynberg <ig...@gmail.com>.
if you give us a patch soon it might make it into 1.3 :)
-igor
On 8/24/07, Jan Stette <ja...@gmail.com> wrote:
>
> 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 <ig...@gmail.com> 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 <ja...@gmail.com> 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/wicket-develop@lists.sourceforge.net/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
> > >
> >
>
Re: Problem with classloader in Wicket Application class
Posted by Jan Stette <ja...@gmail.com>.
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 <ig...@gmail.com> 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 <ja...@gmail.com> 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/wicket-develop@lists.sourceforge.net/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
> >
>
Re: Problem with classloader in Wicket Application class
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ja...@gmail.com> 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/wicket-develop@lists.sourceforge.net/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
>