if you give us a patch soon it might make it into 1.3 :)
-igor
On 8/24/07, Jan Stette <[EMAIL PROTECTED]> 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 <[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
> > >
> >
>
