I used to add custom FormValidators to forms where multi-field validation was required (like checking if two copies of an entered password match. However, this approach has some problems – I had to list the dependent components and if some of them were hidden at validation time, the validator didn’t work. Reading around, I saw the recommendation to use the onValidate() method of the form to do validation and this seems a lot more straightforward. Here’s a sample wicket form with some validation logic to check if the current password matches and if the two copies of the new password are the same. [code language=”java”] final Form form = new Form("form", new CompoundPropertyModel(user)) { private static final long serialVersionUID =[…]
Tag: Java
After fooling around with other methods, we finally accepted the advice I got on the Wicket IRC channel and used Terracotta to cluster our Wicket-based apps running under Jetty. It turned out to be straightforward to implement. The first thing to do was to add the Terracotta dependencies to our pom.xml. [sourcecode language=”xml”] org.terracotta.session terracotta-session 1.1.1 org.terracotta terracotta-toolkit-1.1-runtime 2.0.0 [/sourcecode] Then you just need to add a Terracotta filter to the jetty WebAppContext as follows: [sourcecode language=”java”] FilterHolder tcFilterHolder = new FilterHolder(TerracottaJetty61xSessionFilter.class); tcFilterHolder.setInitParameter(“tcConfigUrl”, “terracotta:9510,terracotta2:9510”); context.addFilter(tcFilterHolder, “/*”, Handler.ALL); [/sourcecode] That’s it. Terracotta will cluster the session (in the example we’re using two terracotta servers called “terracotta” and “terracotta2” – a main server and a standby). We’re using a HAProxy load-balancer with[…]
Hazelcast (hazelcast.com) provides an easy way to implement distributed locking to allow your applications to run multiple, fault-tolerant instances without worrying about issues related concurrent access to shared resources (like files, databases or whatever). [sourcecode language=”java”] try { java.util.concurrent.locks.Lock lock = Hazelcast.getLock(“mylock”); while (true) { lock.lock(); try { // do some work involving access to shared resources } finally { lock.unlock(); } } } finally { Hazelcast.shutdown(); } [/sourcecode] We have an SMS server which retrieved mail messages from a POP3 mailbox, entered them to a database and then delivered via the Clickatell messaging gateway. Making it run multiple instances concurrently would have been a headache since it would involve various issues relating to transactions across the POP3 and the[…]
Many of our applications require scripting support (allowing users to create scripts to customize workflow within the application). Java provides very straightforward scripting via the javax.script script-engine library. A simple integration is shown below where a Javascript onSave method provided by the user is called, if available, passing a business-logic object “item”:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
import javax.script.Invocable; import javax.script.ScriptEngine; import javax.script.ScriptEngineManager; import javax.script.ScriptException; public class Scripting extends Base { private ScriptEngineManager mgr; private ScriptEngine engine; private Invocable invocable; private boolean initialize (String script) { mgr = new ScriptEngineManager(); engine = mgr.getEngineByName("js"); try { engine.eval(script); } catch (ScriptException e) { warn("The script could not be loaded: " + e.getMessage()); return false; } invocable = (Invocable)engine; return true; } public void onSave(Item item) { try { invocable.invokeFunction("onSave", item); } catch (ScriptException e) { warn("The onSave method of the script caused an error: " + e.getMessage()); } catch (NoSuchMethodException e) { // no onSave method provided by the user - that's OK, just ignore it } } } |
Note: the javax.script library supports multiple scripting engines including javascript, python, groovy and java. Javascript was the easiest to get working because the Rhino Javascript engine is included in JDK 6.