Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.7DR#2
-
Fix Version/s: 1.7.2
-
Component/s: None
-
Labels:None
-
Environment:ICEfaces, glassfish-v2-ur1-b08
-
Workaround Exists:Yes
-
Workaround Description:
Description
GlassFish/Grizzly integration is now working well with the auctionMonitor, however occasional NullPointerExeptions were seen with WebMC. The following workaround and debugging code was applied for this. The NullPointerException is due to the getScheme() returning null on the request. A current version of GlassFish must be tested with WebMC to verify this.
+++ src/com/icesoft/faces/webapp/http/servlet/ServletRequestResponse.java (working copy)
@@ -45,7 +45,18 @@
public void servlet(Object request, Object response) {
HttpServletRequest req = (HttpServletRequest) request;
String query = req.getQueryString();
- URI uri = URI.create(req.getRequestURL().toString());
+ URI uri = null;
+ try {
+ uri = URI.create(req.getRequestURL().toString());
+ } catch (Exception e) {
+ System.out.println("building our own URI " + e);
+ uri = URI.create("http://" + req.getServerName() + ":"
+ + req.getServerPort() + req.getRequestURI());
+ System.out.println("Constructing URI " + uri + " scheme " + req.getScheme());
+ }
+ }
requestURI = (query == null ? uri : URI.create(uri + "?" + query));
}
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Has the original problem been verified by QA? If so, they can mark as resolved if it's verified fixed.
A supported customer is getting a similar error on Tomcat 5.0.28 with ICEfaces 1.7.1 and in IE7. They are updating data that is linked to a chart they have in their application. The error is thrown on every update. Here is the error they are getting:
2008-07-16 10:43:51,230 [http-8080-Processor25] ERROR http.servlet.ServletRequestResponse - Null Protocol Scheme in request
java.lang.NullPointerException
at org.apache.coyote.tomcat5.CoyoteRequest.getRequestURL(CoyoteRequest.java:2068)
at org.apache.coyote.tomcat5.CoyoteRequestFacade.getRequestURL(CoyoteRequestFacade.java:511)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse$1.servlet(ServletRequestResponse.java:54)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.detectEnvironment(ServletRequestResponse.java:222)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.<init>(ServletRequestResponse.java:47)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.<init>(ThreadBlockingAdaptingServlet.java:32)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:18)
at com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:63)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:139)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:53)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:595)
This has been reduced to debug level logging to reduce the symptoms of the problem. However, the bug still remains. Does the customer have a test case that we could use to solve the root cause?
Fixes are now checked in to the trunk and branches/icefaces-1.7
I am currently unable to reproduce this bug, but I believe that Jack has seen it on his system. Jack, can you confirm this?
Marking this as resolved, since the workaround is checked in. However, we still need to verify that this is indeed a GlassFish bug (not an ICEfaces bug) and advocate the fix in GlassFish.