> I worked around this by extending the WicketFilter with the override:
>
> protected ClassLoader getClassLoader() {
> return Thread.currentThread().getContextClassLoader();
> }
>
> so that my new WicketFilter would keep the default context class loader.
> Mow I can stick all my wicket jars in the servers lib directory instead
> of having to put them in the webapps lib directory.
Oooops. I just found out that WicketFilter in 1.3 works nicely - like
you did Dan, it returns the context class loader, but for some reason
2.0 return the loader of the class. This was a bug and is fixed now
(so you can get rid of that filter again Dan).
People if you ever come across a situation where you wonder whether it
is really a good idea that something is done, and certainly when that
forces you to create a workaround, please report. It might be a bug,
like in this case, or we might save you time and annoyance providing
you a better alternative.
Cheers,
Eelco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
