ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Thanks, I'll give that a try.

Actually there is a "workaround" for the @RequestParameter bug.

SEAM 1.1 expanded the EL with support for parameterized JSF method bindings (see Chapter 18 of the SEAM reference).

You can now build something like that:

Code:

<h:commandLink value="#{messages['view.text.scrollMinus']} " action="#{searchAddressAction.refreshList('prev)}" />

and have your bean method like
Code:

public String refreshList(String pageIndicator);

I was wondering if there is a possible configuration solution, that allows me to use ICEfaces only for dedicated JSF pages?

The only thing I came up with is using separate url-patterns in the web.xml for the ICEfaces Servlets and the normal JSF Servlet.
But this would leave me with the problem of having one view-handler specified in my faces-config.xml.

Any ideas?

I am actually trying to adapt my existing SEAM application to use ICEfaces.
Using the KB article I am fine so far, but encountered one annoying error.
Code:

14:00:15,062 ERROR [D2DFaceletViewHandler] Problem in renderResponse: /view/login.xhtml @33,59 test="${! empty facesContext.maximumSeverity}" /view/lo
 gin.xhtml @33,59 test="${! empty facesContext.maximumSeverity}": com.icesoft.faces.context.BridgeFacesContext
 com.sun.facelets.tag.TagAttributeException: /view/login.xhtml @33,59 test="${! empty facesContext.maximumSeverity}" /view/login.xhtml @33,59 test="${!
  empty facesContext.maximumSeverity}": com.icesoft.faces.context.BridgeFacesContext
 .
 .
 .
         at java.lang.reflect.Method.invoke(Method.java:585)
         at org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:400)
         ... 61 more
 Caused by: java.lang.UnsupportedOperationException
         at com.icesoft.faces.context.BridgeFacesContext.getMaximumSeverity(BridgeFacesContext.java:124)
         ... 66 more

With looking in the ICEfaces code, this is clear, cause BridgeFacesContext.getMaximumSeverity only throws a new UnsupportedOperationException.

I have used this method on nearly every page to check if there are messages or to determine if the messages are errors or just information
because the error handling with h:message and h:messages didn't fit my needs.

Is there another way to get these information?

Is there another