RE: Facelet compilation error handling in portlet

2010-08-05T07:13:12Z

This bug is fixed in current trunk - Mojarra 2.1.0

But I think the first release of bridge will not support 2.1 version :-(

RE: Facelet compilation error handling in portlet

2010-08-04T07:12:50Z

Neil Griffin:

I think this might be a case of Mojarra swallowing an exception, and perhaps they should be logging it. Would you agree? If so, then you can create an issue for the Mojarra team at Oracle here: https://javaserverfaces.dev.java.net/issues/

Post this issue to mojarra team:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1759

Facelet compilation error handling in portlet

2010-08-03T08:06:52Z

Environment: Liferay 6.0.4, Jsf 2.0.3, Bridge ALPHA4

After creating one simple facelet, I made a mistake and did not put a closing span tag after the opening.

It took me about half a day to understand why my portlet brokes, because in stack-trace I only see this.

1
207:33:26,109 ERROR [jsp:154] java.lang.IllegalArgumentException: null source
3 at java.util.EventObject.<init>(EventObject.java:38)
4 at javax.faces.event.SystemEvent.<init>(SystemEvent.java:67)
5 at javax.faces.event.ComponentSystemEvent.<init>(ComponentSystemEvent.java:69)
6 at javax.faces.event.PostRestoreStateEvent.<init>(PostRestoreStateEvent.java:69)
7 at com.sun.faces.lifecycle.RestoreViewPhase.deliverPostRestoreStateEvent(RestoreViewPhase.java:256)
8 at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:245)
9 at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
10 at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
11 at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
12 at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:221)
13 at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:194)
14 at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
15 at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
16 at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)
17 at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
18 at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:92)
19 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
20 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
21 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
22 at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)

After debugging with Jsf-sources I found that RuntimeException of type javax.faces.view.facelets.FaceletException: Error parsing ....
is created after a call:

1ViewMetadata metadata = vdl.getViewMetadata(facesContext, viewId);

in RestoreViewPhase.class

which executes line

1Facelet f = faceletFactory.getMetadataFacelet(result.getViewId());

in ViewMetadataImpl.class

This call is actually executing this line in DefaultFaceletsFactory.class:

1FaceletHandler h = this.compiler.metadataCompile(url, alias);

During execution of this line exception is thrown and than catched in DefaultFaceletCache.class in method:

1
2public DefaultFacelet getFacelet(URL url) throws IOException {
3       DefaultFacelet f = null;
4       try {
5          f = _faceletCache.get(url).getFacelet();
6       } catch (ExecutionException e) {
7          _unwrapIOException(e);
8       }
9       return f;
10}

And then rethrown as RuntimeException in this DefaultFaceletCache.class method:

1
2private void _unwrapIOException(ExecutionException e) throws IOException {
3       Throwable t = e.getCause();
4       if (t instanceof IOException) {
5          throw (IOException)t;
6       }
7       if (t instanceof RuntimeException) {
8          throw (RuntimeException)t;
9       }
10       throw new FacesException(t);
11}

Then this exception is returning to RestoreViewPhase.class, but stays uncatched there, so the execution is going to the finally block to line

1deliverPostRestoreStateEvent(facesContext);

Which then causes the null exception due to ViewRoot is null.

I wonder, is there a way to catch those kind of errors and display error description in porltet body, without the need to debug JSF sources?
Because during development, it is easy to make some mistakes in xhtml markup of facelet and then it is hard to find what line causes the error.

RE: More JSTL features in facelets ?

2010-08-03T06:02:13Z

What about <portlet:actionUrl/>, <portlet:defineObjects/> and other useful standard portlet tags in faceletes? Is there any analogous to these tags in faceletes environment?

RE: More JSTL features in facelets ?

2010-07-27T21:09:16Z

I wonder why did I ask this question and what's happening to me .... Sure I use setPropertyActionListener ....

More JSTL features in facelets ?

2010-07-27T12:13:22Z

Hello all !

Maybe this isn't best place to ask about JSTL and Facelets, but I count on your tolerance ;) -

Is there any newer version of

com.sun.faces.facelets.tag.jstl.core that would let me do this:

<c:set var="userId" value="#{jobOffersModel.getSelectedJobOffer().getUserId()}" />
<c:set target="#{vjfUserActionsModel}" property="userId" value="#{userId}" />

as for now c:set target is not supported...

Thanks to jobss I can do

#{vjfUserActionsModel.setUserId(jobOffersModel.getSelectedJobOffer().getUserId())} but I was

wondering whether there is something else ?

Is there a good forum for JBoss EL and/or facelet questions... ?

jsf / facelets / jstl

RE: Facelet compilation error handling in portlet

RE: Facelet compilation error handling in portlet

Facelet compilation error handling in portlet

RE: More JSTL features in facelets ?

RE: More JSTL features in facelets ?

More JSTL features in facelets ?