How to debug EL in the JSF page? I'd like to watch variable values, function calls an so on. The best solution would be an eclipse plugin, but any other possibility is better than guessing "Why this expression failed to render correctly?".
相关问题
- java.lang.NullPointerException at java.io.PrintWri
- h:selectOneMenu in p:dataTable doesn't submit
- Pass custom debug information to Microsoft bot fra
- Eclipse and Mylyn : how to disable grey files in t
- Installing Pydev for Eclipse throws error
相关文章
- selenium+eclipse 打开网页时报错
- Eclipse failing to open
- Eclipse how can I indent C++ preprocessor macros
- Why is FindBugs ignoring my check for null?
- How do I get to see DbgPrint output from my kernel
- Eclipse cleanup - what are the “.index” files - ca
- Eclipse plugin to find out unused methods in a cla
- Spring NamespaceHandler issue when launching Maven
Closest what you can get in JSF/Facelets is placing an
<ui:debug />
somewhere in the view:Pressing CtrlShiftD should then show a popup window with debug information about the component tree and all available request parameters and request/view/flash/session/application scoped variables. It's basically a representation of the content of all those maps.
The hotkey is by the way configureable by
hotkey
attribute so that you can choose another whenever it clashes with browser default hotkeys, as it would do in Firefox; CtrlShiftD would by default show the Add bookmarks dialogue. Here's how you could make it to listen on CtrlShiftX instead:You'd usually also like to hide it in non-development stage, so add a rendered condition like that:
In the shown debug information, the information provided about scoped variables isn't that great as you would expect. It only shows the
Object#toString()
outcome of all scoped variables which defaults tocom.example.Bean@hashcode
. You can't explore their properties and the values of their properties directly like as you could do in debug view of Eclipse's debugger. You'd need to implementtoString()
on the class accordingly so that as much as possible relevant information is returned (if necessary, you can even let Eclipse autogenerate it by rightclick source code > Source > Generate toString()):As to method calls, just put a breakpoint on the Java source code the usual way. Eclipse will kick in there as well when EL calls the method. If it's a managed bean, you'll also just see its properties in the Eclipse debugger.
If you are really having problems then if you can get the source for the EL implementation (easy enough for the RI) then you can use Eclipse to set breakpoints in the EL implementation methods. You need to get an understanding of how the EL code works, but it isn't that complicated. Not for the very faint hearted though.
Another possibility would be to create and evaluate the EL programatically. There are examples of how to do this around. You can then use the debugger to fiddle around with what the expression is and what the result is until you've worked out where your problem lies.