yes it could we should test for null anyway (and then take the wicket
classloader)
But then the resource will NOT be lookup for the class the static
resource would be in... (possible in the oscar situation)
I don;'t know how you test the context classloader??
Did you just get it??
Because if you want to use a context classloader. you should SET it
first at some point...
Or else you have the context classloader of something that is mostly i
think set by the web container (so the current web app classloader)
and that doesn't work because that one we already have.
Most of the time if you use context classloader you do something like this:
Thread.currentThread().setContextClassLoader()
// do youre call
Thread.currentThread().setContextClassLoader(previous_one)
Martijn Dashorst wrote:
I'm more inclined to resolve it at the end of the stacktrace: when the
parameter is null, it should resolve to the context classloader Gili
and Cameron proposed. This way no more null pointers.
Martijn
Johan Compagner wrote:
looked at the code and i don;t think this will work:
private PackageResource(final Package basePackage, final String path,
final Locale locale,
final String style)
{
packageClass = basePackage.getClass();
and use that packageClass later on:
this.resourceStream =
Application.get().getResourceStreamLocator().locate(
packageClass.getClassLoader(), absolutePath,
style, locale, null);
Because the class that is used there is the the Package.class (the
one of the system classpath)
its a pitty that this: ClassLoader.getCallerClassLoader() is hidden
from use to call..
or else we could do:
private PackageResource(final Package basePackage, final String path,
final Locale locale,
final String style)
{
packageClass = ClassLoader.getCallerClassLoader();
I think the only way is to refactor PackageResource for this
And give us a class instead of a package.
johan
Dariusz Wojtas wrote:
The code that worked in the morning, retrieved from HEAD, does not
work anymore now.
Just a call to DatePicker resources produces a stacktrace on the
appserver console.
The stacktrace below appears for me for every datapicker resource
referenced from generated HTML page. My code has not changed - worked
in the morning with HEAD.
Now it stopped.
I am using eclipse + Jetty
23:29:30.546 WARN!! [SocketListener0-1]
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:588)
11>
/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js:
java.lang.NullPointerException
at
wicket.util.resource.locator.ClassLoaderResourceStreamLocator.locate(ClassLoaderResourceStreamLocator.java:58)
at
wicket.util.resource.locator.AbstractResourceStreamLocator.locate(AbstractResourceStreamLocator.java:109)
at
wicket.util.resource.locator.DefaultResourceStreamLocator$1.locate(DefaultResourceStreamLocator.java:53)
at
wicket.util.resource.locator.ResourceStreamLocator.locate(ResourceStreamLocator.java:124)
at
wicket.markup.html.PackageResource.getResourceStream(PackageResource.java:181)
at
wicket.protocol.http.WicketServlet.getLastModified(WicketServlet.java:338)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:592)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
at org.mortbay.http.HttpServer.service(HttpServer.java:954)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
