If you’re trying to deploy a war under Tomcat and it isn’t going like it should be, the first thing you do is look in the console if you ran it from a console, or the log files in Tomcat’s homefolder otherwise. Now this provides you with some details as to why something went wrong, but there is the chance that de application itself is throwing exceptions unlogged which are caught by Tomcat. Those are not logged by default by Tomcat! To log these as well, you’ll need to utilize log4j.
You’d be surprised how hard it is to find good information about how you’re supposed to setup validators that you can parameterize with attributes in your tags; most about validators is very basic and very JSF-only. Or you won’t be surprised at all, because you searched until loss of sanity like me and found this blog. Whatever, here you can read what I found out.
So at first I made the error in not realizing validators under Facelets should be defined in their own facelets tag library. I hadn’t really worked myself into the the theory behind Facelets; I just picked it up as I went… as I do with most things, but there you have it. Turns out Facelets actually makes things very easy concerning validators, were it not for one sneaky little detail:
“parameterizable validators are stateful validators“
We’ll come back to it, but validators generally lose state after the page has been built by Facelets and you have to manually restore that state (including the previously set parameters), by implementing the StateHolder interface.
Oracle has a good article on StateHolder Validators, though I only found it after I learned what to look for.
I resorted to a rather crude catch’em all solution, that tucks away the boilerplate code involved.
Here’s a quick tip I found very useful in Windows, involving Eclipse template system and the @Author annotation.
Say you are working under some kind of account, for example some assigned number combination which you use to log into Windows or something. Mine recently was AA170738. Now say you are editing Java classes in Eclipse and generating comments with Eclipse. You might end up with something like this:
| 1 2 3 4 | /** * @author AA170738 * */ |
I Found this very annoying since it happened to me for every class I introduced and templates are supposed to save time. You could ofcourse turn it off entirely, Preferences->Java->Editor->Templates->uncheck @author, but I just wanted it fixed the right way.
Turns out Eclipse simply reads out the Java system property user.name. All we need to do then is boot Eclipse with an explicit system property. Like so…
eclipse.exe -vmargs -Duser.name=”John Doe”
Just change that in your shortcut and you’re set.
| 1 2 3 4 | /** * @author John Doe * */ |
Direct Web Remoting, or DWR in short, is a technology that helps you ease the development of javascript based applications using a Java server. What it does is simply sit in between your javascript and your java classes and acts as marshaller for method calls from javascript to Java. In a nutshell: DWR provides Remote Procedure Calls for javascript and is a great library for use in Ajax enabled webapplications.
This isn’t yet another blogpost about what DWR exactly is or why it is so cool; the objective of my post today is to simply set up a quick example of how to work with it. A quick tutorial if you will. I’m the kind of guy that likes many examples and diagrams and whatnot to take apart and learn from, so here’s my contribution to the ‘code by example’ paradigm. If you want to know more about DWR before actually trying to use it, I suggest you check out the DWR homepage.