Skip to main content

Debugging JSF2 / XHMTL pages

8 replies [Last post]
lostinspace2011
Offline
Joined: 2007-08-01
Points: 0

I am busy porting a JSP1.2 application to JSF2 but I am getting some strange errors. For now I was able to guess my way around this problem, but I am a little confused as there is no details pointing me to the cause of this issue. In all cases so far it was either something not being declared or a typo, however for larger pages it is difficult to find the the cause. I am using tomcat 6.0.24 and Mojarra 2.0.3 (FCS b03).

<br />
javax.servlet.ServletException: null source<br />
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:321)<br />
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)<br />
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)<br />
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)<br />
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)<br />
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)<br />
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)<br />
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)<br />
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)<br />
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)<br />
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)<br />
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)<br />
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)<br />
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)<br />
	at java.lang.Thread.run(Thread.java:637)<br />
Caused by: java.lang.IllegalArgumentException: null source<br />
	at java.util.EventObject.(EventObject.java:38)<br />
	at javax.faces.event.SystemEvent.(SystemEvent.java:67)<br />
	at javax.faces.event.ComponentSystemEvent.(ComponentSystemEvent.java:69)<br />
	at javax.faces.event.PostRestoreStateEvent.(PostRestoreStateEvent.java:69)<br />
	at com.sun.faces.lifecycle.RestoreViewPhase.deliverPostRestoreStateEvent(RestoreViewPhase.java:256)<br />
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:245)<br />
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)<br />
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)<br />
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)<br />
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)<br />
	... 14 more<br />

Any pointers on what I could do to make it easier to find the problem.

Thanks in advance

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lostinspace2011
Offline
Joined: 2007-08-01
Points: 0

Yes, thanks. Using the XML validator in Netbeans has been very useful. Once I got used to dealing with this kind of problem.

andrewlaughlin
Offline
Joined: 2010-03-19
Points: 0

I've fought this error as well. After debugging through the 2.0.3 source it initially appeared the UIViewRoot element was somehow turning up null. Hence the reason for the "null source" and empty component tree output in the web browser. After digging a little further, I discovered there was an exception being thrown in the DefaultFaceletCache class:

public DefaultFacelet getMetadataFacelet(URL url) throws IOException {
DefaultFacelet f = null;

try {
f = _metadataFaceletCache.get(url).getFacelet(); // Exception thrown here.
} catch (ExecutionException e) {
_unwrapIOException(e);
}
return f;
}

In my case the exception was:
"Error Parsing /sign_in.xhtml: Error Traced[line: 26] The element type "meta" must be terminated by the matching end-tag ""." However, the exception is subsequently swallowed and never sees the light of day.

Long story short -- XHTML requires all tags to be terminated, and in my case, the tag wasn't. Terminating the tag corrected the issue.

Andrew

manuelbernhardt
Offline
Joined: 2010-07-15
Points: 0

Hi Andrew,

> I've fought this error as well. After debugging
> through the 2.0.3 source it initially appeared the
> UIViewRoot element was somehow turning up null.
> Hence the reason for the "null source" and empty
> component tree output in the web browser. After
> digging a little further, I discovered there was an
> exception being thrown in the DefaultFaceletCache
> class:
>
>
> public DefaultFacelet getMetadataFacelet(URL url)
> throws IOException {
> DefaultFacelet f = null;
>
> try {
> _metadataFaceletCache.get(url).getFacelet(); //
> Exception thrown here.
> } catch (ExecutionException e) {
> nwrapIOException(e);
> }
> return f;
> }
>
> In my case the exception was:
> "Error Parsing /sign_in.xhtml: Error Traced[line: 26]
> The element type "meta" must be terminated by the
> matching end-tag ""." However, the exception
> is subsequently swallowed and never sees the light of
> day.

I started my debugger and tried that out, also saw it getting thrown there, but what's more problematic I think is that on its way up the chain encounters a finally in com.sun.faces.lifecycle.RestoreViewPhase#execute (line 245 in 2.0.3)

[code]
finally {
deliverPostRestoreStateEvent(facesContext);
}
[/code]

which in turn tries to get the view root to construct a PostRestoreStateEvent, and that one being null, it ends up delivering a rather unusable message to the user.

The constructor of PostRestoreStateEvent says:

[code]
*

Instantiate a new
* PostRestoreStateEvent that indicates the argument
* component just had its state restored.

[/code]

Given that when there's a problem in the XHTML tree, there's nothing much that can be restored, I'd say that it is probably safe to discard the firing of that event (e.g. by doing a null check on the view root prior to calling the method in the finally block). But I don't know what the spec says there, would have to look it up.

> Long story short -- XHTML requires all tags to be
> terminated, and in my case, the tag wasn't.
> Terminating the tag corrected the issue.

Sure, but then again as Mojarra user I would like to get the error message telling me where I messed up (especially when you get this kind of beast for the first time, it's a bit distressing).

Will try to find some time this week-end and make a unit test that demonstrates that case (if it wasn't already reported and fixed).

Cheers,

Manuel

manuelbernhardt
Offline
Joined: 2010-07-15
Points: 0

Hi again,

actually the issue has already been filed:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1758

Manuel

andrewlaughlin
Offline
Joined: 2010-03-19
Points: 0

Hey Manuel, I agree. This exception should be allowed to propagate so the user can see why the request actually failed.

Glad to see it has been brought to the developer's attention.

Best Regards,
Andrew

lostinspace2011
Offline
Joined: 2007-08-01
Points: 0

It ended up being some jsp scriptlets. Using Netbeans Check XML feature helped a little. What are my option to port scriptlets into the new era of JSF2?

jimo
Offline
Joined: 2008-10-13
Points: 0

Under opensource Glassfish 3.0.1with Mojarra 2.0.3 (FCS b03), the exception looks the same as your posted 'caused by'

I stare at my source for a while then, if I can't find the problem, copy/paste into http://validator.w3.org/#validate_by_input

manuelbernhardt
Offline
Joined: 2010-07-15
Points: 0

I can confirm that this problem shows up, I have had it quite a number of times. Usually for me, the following two mistakes lead to the stacktrace:
- unbalanced quotes in tags, e.g.
- unbalanced tags, like forgetting to change the closing tag when changing the opening tag

I agree it's quite unsettling to get such a stacktrace, especially that those things are not the easiest to spot if your IDE doesn't tell you so.

I haven't gotten around to debug into this, however I have a hunch that this may be related to deploying on tomcat... I would think that more people would complain about this if it happened on e.g. Glassfish.