This is in continuation with my previous question. I couldn't find solution for that. Hence I am trying to debug my application view layer jspx.
I realized that jspx is quite different from jsp, like it doesn't allow scriptlets. I know, that usage of this(scriptlets) is not at all recommended.
I have a particular SAP Net weaver server where hot deployment of jspx/jsp/html is not working. I have checked other alternatives like remote debugging, break points in jspx. But, its SAP net weaver, have some configuration issues. I have one option atleast to put sysouts, to trace runtime exceptions. But as its jspx files sysouts in scriptlets are not working. If it was jsp instead of jspx there, I could have traced/debugged the issues quickly using scriptlets temporarily until the issue got resolved atleast by using Sysouts.
Is there any equivalent code to this scriptlet(used in jsp)which we use very rarely.
<% System.out.println("The line above the null pointer exception : "+object.getPropery());%
Any equivalent code in jspx or icefaces components.
How do we debug a jspx page or handle exceptions inside a jspx page and find out errors.
Any eclipse plugins or tools available?
Related
In server log multiple errors can be found like below
java.lang.NullPointerException at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:95)
What can be the possible reason for this? Though I tried to recreate in I am unable to recreate after several attempt. Any possible reason or any idea related to this issue?
I need to understand why can we get null pointer exception while rendering response in JSF/Primeface?
primefaces v.3.4.1
javax.faces v.2.1.18
if I check the source code of JSF issue is at this line of source code
ViewDeclarationLanguage vdl =
vh.getViewDeclarationLanguage(facesContext,
facesContext.getViewRoot().getViewId());
javax.faces.STATE_SAVING_METHOD is set to server.
Check you xhtml file for any not closed tags or other xml/html issues. For example divs. Id your IDE doesn't do that, then change IDE or use online XML validators.
Is there any way to determine what line (or even what file) is causing the
The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within
warning message from Primefaces? I just began working on an established project with many, many .xhtml files (written by others) with all sorts of templates and inheritance and I'm having trouble narrowing down what file is causing the issue.
I've tried googling with no luck, and I can't find an answer on SO that addresses how to find the source of the error.
Update: It's not as simple as going to the page shown in the url. For example, the warning displays when I navigate to '../foo.xhtml', however, foo.xhtml implements a template and inclues multiple other .xhtml files (which in turn each include a few more .xhtml files). All of the files are somewhat sizeable (at least 500 lines).
Put a debug breakpoint in FormOmittedChecker#check(), inside the if block where isInNeedOfForm(component) has returned true, which is line 99 as of Mojarra 2.2.12.
96 if (isForm(component)) {
97 result = VisitResult.REJECT;
98 } else if (isInNeedOfForm(component)) {
* 99 addFormOmittedMessage(finalContext);
100 }
Given a page with an input field without a <h:form>,
<h:inputText id="someInputText" />
the breakpoint hit will look like below in Eclipse:
As you see on the screenshot, you can inspect component variable in the variables stack and then inspect its clientId (or id) property. Finally you can just locate and correlate it in generated HTML output and/or JSF source code.
I however do agree that the message should contain better diagnostic. This was fixed in Mojarra 2.3.0-m04 as per issue 4026.
Have a simple question. Let's consider the following tag.
<h:inputText id="text" value="#{bean.value}"/>
If it is mistakenly written as follows.
<h:inputText id="text"value="#{bean.value}"/>
Please notice that there is no space between the id and the value attributes in this case. This is expected to be a parse error that should occur during parsing of the XHTML file possibly throwing an appropriate exception.
If it were to happen, absolutely nothing exceptional would be reported. No errors/exceptions would be thrown on the server-side. The target web page on the browser would then merely be left blank (white) in its entirely which would also indicate no errors as obvious on the client-side, since parsing of the file happens on the server-side.
Additional Information :
This already happened to me several times on XHTML files having several lines of code even though extreme care is exercised/taken. Mostly happens during copy/pasting which is many a times essential.
If it were to happen, the only way to trace the error was scan the XHTML document manually starting from the first line, all the way down to the last line (or the trace line, if one is caught) possibly scrolling in the middle through a long, ugly horizontal scroll bar on the IDE's GUI too.
Fortunately, I duplicated the same application twice - once using Java EE and again using Spring hereby XHTML code was same in both of the projects. I had been solving this problem as of now, since I began those applications in parallel by copy/pasting the whole XHTML code from one project to another, when it happened and I was unable to trace the line by average attempts. This is not always an alternative.
Can it get to throw an exception, when an XHTML document is mal-formed in this way? Are there someways to make it debuggable/traceable so that one can get rid of manual/tedious/time-consuming/eye-stretching tracing of an XHTML document?
I have a problem I can't quite get a handle on.
First the context: I am developing a web application using Primefaces 3.5 (yes, unfortunately I am stuck with this old version for now), running on JBoss 7.
There is a form with id "form" encompassing all following xhtml code.
I have a component in my view which is provided by usage of the binding attribute:
<p:dashboard id="dashboard" binding="#{myBackingBean.dashboard}" />
Then sometimes I would like to perform an ajax update on this component, this is done by using the RemoteCommand component of primefaces:
<p:remoteCommand
actionListener="#{myBackingBean.someActionListener()}"
process="#this" id="myRmtCmd" oncomplete="myJsFunction();"
update=":form:dashboard" name="myRemoteCommand" />
The RemoteCommand is triggered by a clicking on a Link:
Some Text
This works pretty well so far. However after deploying this code to production I sometimes get a FacesException:
javax.faces.FacesException: Cannot find component with identifier ":form:dashboard"
referenced from "form:myRmtCmd".
This is where my problem lies because I cannot reliably reproduce this exception. My question is this: What could lead to this exception being thrown? It seems to work 95 % of the time but being the perfectionist I am (and many of you reading this are as well, I'm sure ;) ) I would like this code to work 100 % of the time. What am I missing?
Before answering please consider these constraints:
yes, i have to use the binding attribute for providing the dashboard as I need a great deal of control over what gets added to the component
to avoid using IDs I also tried updating the dashboard by its css class via one of primefaces' advanced selectors: #(.ui-dashboard) - this also does not work!
yes, it would be possible to use a commandbutton/link instead of wiring up the remotecommand component to a simple html link but in this case the link is rendered by a JSF renderer component and I made some bad experiences with dynamically adding buttons etc (due to JSF Spec Issue 790)
Cheers,
p.s.
I also had this weird behavior.
There are probably more than one component bindded to #{myBackingBean.dashboard}, so the first one sets the id and there will be no one called "dashboard".
I would like to log the exceptions that are thrown when serving JSF files in the same way other exceptions are logged in our web application.
We annotate classes with logged exceptions with #LoggedExceptions and a MehtodInterceptor is matched against those classes with Guice AOP (This should be very similar for other implementations of aopalliance...)
The main problem is, that the method interceptor does not work. How can i intercept method calls on JSF-backing code?
You must replace the default el-resolver (<el-resolver> in faces-context.xml) with a Guice el-resolver, so that the jsf beans become instantiated by Guide.
Search for "Guice el resolver", or take this one (I can't guarantee it works). Also check this thread.
Also, read the top results of this google search