ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Can you tell me what exactly has been fixed?

I am facing an issue, where server randomly shows the exception "Query does not contain parameter named: ice.view.active"
- and the browser is hanging because it's not getting a response. Is this the same error?

Thanks for the reply. Good to know that there will be a solution soon. But please note that in contrast to the description in JIRA, Firefox does not work fully. You still have the issue, that ICEFaces scripts are not embedded correctly, if the path of the error page does not align with the path of the view in which the exception occurred.

Until the fix is out here is a workaround that does the job in my case:

Declare a good old JSP error page
Code:

<error-page>
     <exception-type>java.lang.Throwable</exception-type>
     <location>/errorRedirect.jsp</location>
 </error-page>

with the following content for errorRedirect.jsp
Code:

 <% // generate a redirect as ICEFaces would do
 response.setContentType("text/xml;charset=UTF-8");
 response.setStatus(200);
 
 // copy error objects to the session if you want to see details on the error page
 session.setAttribute("_error_message",
    request.getAttribute("javax.servlet.error.message"));
 session.setAttribute("_error_exception_type",
    request.getAttribute("javax.servlet.error.exception_type"));
 session.setAttribute("_error_exception",
    request.getAttribute("javax.servlet.error.exception"));
 session.setAttribute("_error_status_code",
    request.getAttribute("javax.servlet.error.status_code"));
 session.setAttribute("_error_request_uri",
    request.getAttribute("javax.servlet.error.request_uri"));
 session.setAttribute("_error_servlet_name",
    request.getAttribute("javax.servlet.error.servlet_name"));
 %>
 <redirect url="<%=request.getContextPath()%>/error.iface"/>

Then the error page error.jspx can display some information about the exception:
Code:

 <f:view
   xmlns:f="http://java.sun.com/jsf/core"
   xmlns:ice="http://www.icesoft.com/icefaces/component">
   <html>
   <head>
   <title>Error Page</title>
     <ice:outputStyle rel='stylesheet' type='text/css' href='./xmlhttp/css/xp/xp.css'/>
   </head>
   <body >
     <ice:panelGrid columns="2">
       Message:
         <ice:outputText value="#{sessionScope._error_message}" />
       Type:
         <ice:outputText value="#{sessionScope._error_exception_type}" />
       Exception:
         <ice:outputText value="#{sessionScope._error_exception}" />
       Status Code:
         <ice:outputText value="#{sessionScope._error_status_code}" />
       Request URI:
         <ice:outputText value="#{sessionScope._error_request_uri}" />
       Servlet Name:
         <ice:outputText value="#{sessionScope._error_servlet_name}" />
     </ice:panelGrid>
   </body>
   </html>
 </f:view>

Error pages seem to work with Firefox but not with InternetExplorer 6 and 7. IE just shows an empty page. Firfox displays the content of the error page.

There seems to be no difference in the reaction of the server. Using an HTTP sniffer I can see that a POST request goes to /myapp/block/send-receive-updates (that's normal). After the exception has been thrown the server produces a response with the contents of the error page, like

Code:

HTTP/1.1 500 javax.faces.el.EvaluationException: javax.servlet.ServletException: ...
 ...
 Connection: close
 
 <!DOCTYPE HTML PUBLIC "...>
 <html lang="de">
 <head id="head">
 <title>Error Page</title>
 <link href="./xmlhttp/css/xp/xp.css" rel="stylesheet" type="text/css"></link>
 ...

This behaviour is absolutely identical for Firefox and InternetExplorer. Hence there can't be a problem on the server side. I suspect it must be an error in the JavaScript code that handles the error responses of HTTP code 500.

Actually there is another issue that occurs with Firefox: if the error page is a JSF page, ICEFaces gets confused about the right location of the view: if my error page is /error.iface and the exception is thrown by a view /subdir/crash.iface. Then the error page shows the following code snippet

Code:

...
 <script language="javascript" src="xmlhttp/1186572282324/icefaces-d2d.js"></script>
 <script language="javascript" src="xmlhttp/1186572282324/ice-extras.js"></script>
 ...

But this is not correct since the browser still shows the URL of the view /subdir/crash.iface, for instance "http://myserver/myapp/subdir/crash.iface". (like if the contents of the error page were a DOM update?). The issue: the resources are now assumed relative to the current URL, resulting in a request to "http://myserver/myapp/subdir/xmlhttp/....". And the server replies with HTTP 404, the resource is not available.

Consequence: ICEFaces controls on the error page do not work.

It is really a serious issue, that one cannot present a reasonable error page to the user if something goes wrong. There are error conditions in any application (at least in ours). And a blank page, or a never stopping turning connection wheel is what we typically get in these cases. That's just not good enough.

The stack trace looks like it's the same problem I have just posted here: "Wrong Order of Icefaces Requests".

Looking at line 38 in the source code of ViewBoundAdaptingServlet (according to your stack trace), the view obviously must be null when the exception occurs. And if your application works most of the time correctly, ICEfaces must have lost the view.

I have played around with the source and found out that the browser seems to send the requests "dispose old view" and get "new page" in the wrong order. That could very well be an explanation for your issue.

Unfortunately I have no workaround for this issue. I would suspect that it needs to be fixed in the ICEFaces JavaScript code.

I am experiencing exceptions with my ICEfaces 1.6.0#DR5 / Seam 1.2 application.

I have a page with an expandable table. It's very similar to the sample in the ICEfaces distribution. Sometimes when one clicks the expand / contract nodes, there is an exception telling that the Seam conversation cannot be found. This happens particularly when I make the nodes very quickly expand, contract, expand, contract, ...

This is the exception:

Code:

 13:33:50,218 ERROR [D2DFaceletViewHandler] Problem in renderResponse:
      /pricing/viewAdjustPremium.jspx @39,80 itemValue="${layer.value}":
      /pricing/viewAdjustPremium.jspx @38,110 items="#{ctrl.pricingConversation.x}":
      Exception getting value of property pricingConversation of base of type :
      com.agcs.pricing.web.controller.ViewAdjustPremiumController_$$_javassist_39
 javax.faces.el.EvaluationException: /pricing/viewAdjustPremium.jspx @39,80 itemValue="${x.value}":
      /pricing/viewAdjustPremium.jspx @38,110 items="#{viewadjustpremiumcontroller.pricingConversation.x}":
      Exception getting value of property pricingConversation of base of type :
      com.agcs.pricing.web.controller.ViewAdjustPremiumController_$$_javassist_39
      at com.sun.facelets.el.LegacyValueBinding.getValue(LegacyValueBinding.java:60)
      ....

("pricingConversation" is a Seam bean in the conversation scope)

Looking into the ICEfaces source code I saw that the ViewBoundAdaptingServlet that is executed for handling the Ajax request manipulates the view information stored in ServletView. However there is no (or very little) synchronization.

In order to see what's going on I have added a few code statements to the class which looks like this
Code:

 public class ViewBoundAdaptingServlet extends BasicAdaptingServlet {
 
     private int concurrentCalls = 0;
 
 ...
 
     public void service(HttpServletRequest request, HttpServletResponse response) throws Exception {
         if (++concurrentCalls > 1) {
             System.err.println("***************************************");
             System.err.println("** Concurrent calls: " + concurrentCalls);
             System.err.println("***************************************");
             
             ...
             
              finally {
                  view.release();
                  concurrentCalls--;
             }
         }
     }
 }

And indeed - the exception occurs exactly when the number of concurrent calls is 2: everytime the "*****...." appears the exception is thrown. In every request where it does not appear there is no exception. So it looks like there is some systematical logic preventing the Seam conversation from being found when the request is executed in parallel with another.

You have to click a few times in order to produce this situation but you can have it also in the official component-showcase example (without Seam). The component-showcase however does not show an exception (may be due to the lack of a dependency to a running Seam conversation).

So obviously it's possible to execute two concurrent Ajax requests (/pricing/block/send-receive-updates) for the same view simply by clicking repeatedly in the user interface. Why is that? And does it make sense to have them processed concurrently?

I changed the source code of the ViewBoundAdaptingServlet and made the service() method synchronized:
Code:

 public class ViewBoundAdaptingServlet extends BasicAdaptingServlet {
 
     synchronized public void service(HttpServletRequest request, HttpServletResponse response) throws Exception {
        ...
     }
 }

This modification obviously prevents concurrent execution for the user session effectively. And this works great. I cannot produce the exception however fast and often I click on the expand / contract nodes.

What does this mean? Is this an ICEfaces bug? Or could there be any setting I have not done incorrectly?

There are strange exceptions in my ICEFaces 1.6.0#DR5 / Seam application: when I switch from one view to the next the page fails to access the Seam conversation. This happens sometimes - but not always.

The stack trace of the exception looks like this:

Code:

 ERROR [D2DFaceletViewHandler] Problem in renderResponse: /WEB-INF/facelets/tags/button.jspx @13,40 test="${empty disabled}" Stack must not be null
 com.sun.facelets.tag.TagAttributeException: /WEB-INF/facelets/tags/button.jspx @13,40 test="${empty disabled}" Stack must not be null
         at com.sun.facelets.tag.TagAttribute.getObject(TagAttribute.java:235)
         ....
         
 Caused by: java.lang.IllegalArgumentException: Stack must not be null
         at org.jboss.seam.core.ConversationEntry.<init>(ConversationEntry.java:40)
         at org.jboss.seam.core.ConversationEntries.createConversationEntry(ConversationEntries.java:50)
         ....

I have analyzed the ICEFaces source code and added the following debug statement to the SessionDispatcher class in order to see what's going on:

Code:

com.icesoft.faces.webapp.http.servlet.SessionDispatcher:
 	...
         public void service(HttpServletRequest request, HttpServletResponse response) throws Exception {
             System.out.print("== Serving URI " + request.getRequestURI() + ", viewnumber = " + request.getParameter("viewNumber"));
             ...
         }

When everything runs smoothly I can observe the following sequence of incoming requests:

(1)== Serving URI /pricing/block/send-receive-updates, viewnumber = 1

(2)== Serving URI /pricing/block/dispose-views, viewnumber = 1

(3)== Serving URI /pricing/pricing/pricingEntry.seam, viewnumber = null

This is my interpretation:
(1) is the execution of the command button that returns the new view id
(2) ?? seems to instruct Icefaces to remove the view we are just about to leave ??
(3) loads the new view

But sometimes the order of the requests (2) and (3) is exchanged and the output looks like this:

(1)== Serving URI /pricing/block/send-receive-updates, viewnumber = 1

(2)== Serving URI /pricing/pricing/pricingEntry.seam, viewnumber = null

(3)== Serving URI /pricing/block/dispose-views, viewnumber = 1

And then that's the end of the game. The very next action produces the exception above. To me it looks like in this case Icefaces has removed the view AFTER it was loaded and therefore lost the information about the Seam conversation.

This issue seems to be browser dependent because it happens far more often with InternetExplorer than it does with Firefox. It also appears to be particularly frequent when "synchronousUpdate" is set to true.

Any hints what may be wrong?