Richards Blog

More Warped Wicket

Earlier this year I wrote a post on integrating wicket and warp persist, and I thought it was about time I posted an update, but this time I included working example projects.

The first project is a basic wicket / warp persist setup with hibernate and an apache derby database.  It allows you to persist the Event class used in the hibernate examples.

wicketwarp.zip

The second project is the same, but also makes use of warp-servlet for hooking up all your other servlets and filters in guicy way.

wicketwarpservlet.zip

In both cases i’ve tried to keep xml configuration down to a minimum, as I hate xml config.  So the hibernate classes are configured with hibernate annotations.  Wicket itself involves no xml configuration as always.

As warp persist and warp servlet are not in a maven repository (as far as I know) you will need to manually add them into your maven repository in the normal way.

Thoughts, Code patches, Comments, etc are welcome.

More on terracotta and wicket

So recently I have been working on session clustering on Zoomf, which is written in apache wicket.

We decided to go down the terracotta route, because at the time we were running on Jetty and I couldn’t get the WADI clustering to work right, plus terracotta claimed to be easy to get up and running, which in fairness it was. All was going to plan and we deployed the code to our production site. Unfortunately we started running into problems. Basically loads of wicket objects were being created and distributed, because of the way wicket stores pages in its session. With the amount of traffic our site was getting the terracotta distributed garbage collector (dgc) couldn’t keep up, and so the persistent disk store was using up more and more disk space. We’re talking tens of gigabytes here, which is clearly a problem.

After playing around with the different terracotta config options it became apparent that a wicket solution to limit what was distributed was needed.

The simplest solution I could think of was instead of storing the wicket pages as page objects I should serialize them and store them as byte arrays instead. This proved to be as easy as implementing a new wicket IPageMapEntry which does the serialization and deserialization and overriding the getPageMapEntry() method in my base page to make all my pages use the new class.

The new class itself is really simple:

public class NewPageMapEntry extends AbstractPageMapEntry
{
        private transient Page page;
        private byte[] data;
 
        public NewPageMapEntry(final Page page)
        {
                this.page = page;
 
                data = Objects.objectToByteArray(page);
 
                setNumericId(page.getNumericId());
        }
 
        @Override
        public Page getPage()
        {
                if(this.page == null)
                {
                        page = (Page) Objects.byteArrayToObject(data);
                }
                return page;
        }
}

With any luck the new code should be running Zoomf next week and on Tomcat too (tomcats terracotta support is more mature than jettys). If are are interested seeing the progress of this you can read this thread on the terracotta forum, which was extremely useful. A big thanks to all the guys who helped me on there!

EDIT:

I am now working on a better way for to integrate wicket and terracotta, see this thread for more information.

Thoughts on Terracotta

Recently I’ve been working on session clustering with terracotta, jetty and wicket, so I thought I’d write about my experience.

Good points:

• It works!  This may seem a bit silly to state, but other session clustering methods I tried didn’t work and cost me time trying to get them to work.  The time I put into terracotta actually paid off.
• Good support.  Even though the guys that develop terracotta sell consultation services for it they will still help people in the forums.  From finding and reporting a bug in terracotta it was about a week before it was fixed and integrated into the nightly builds.
• Its open source.
• Its versatile, you don’t just have to use it for http sessions.
• A useful admin console for connecting to your terracotta instances (you can even do cluster wide thread dumps in the 2.6 versions).
• It just worked with wicket due to a special wicket integration module (which was included)

Bad Points:

• Lots of config.  Even after you get your system working there is still lots of performance tuning to be done to get the best out of everything (although the admin console in the 2.6 release helps with this).
• Large download (ok this isnt really a bad point in todays world of broadband and terrabyte hard discs).  Does it really need to bundle tomcat?
• Eclipse plugin kept complaining that the config xml file was not valid - it created it for petes sake (ok this is another small point, running through eclipse was very easy with the plugin)

Wicket-Guice and Warp-Persist

This week I came across Warp-Persist, which provides transactional persistence support with Google Guice and Hibernate. To be honest its quite like what Spring provides, but via Guice, which means no nasty XML config files (except for the hibernate one if desired).

I had already been looking at the wicket-guice project which provides support for Guice in Wicket.

The best place to start with integrating these components would be Peter Mularien’s blog post on integrating warp-persist and wicket (but not wicket-guice). Peter’s post, while good, does not cover all of the things that I had to do to get everything working.

1. Add the wicket-guice jar file to your project, if you are using maven then you can easily add the dependancy to your pom.xml file, if not then I think the right jar files (you need wicket-ioc.jar too) are come with the wicket download.
2. Also add the warp-persist jar file which can be obtained here (You don’t have to checkout and build the code yourself). I couldn’t find a maven repo with the warp-persist jar in it so If anyone can point me to one I would be grateful.
3. You will also need the AOP alliance jar file, or you can add it to your maven pom.xml.
4. In your WebApplication.init() method add the call to the GuiceComponentInjector:

   injector = Guice.createInjector(PersistenceService.usingHibernate()
   .across(UnitOfWork.REQUEST).transactedWith(
   TransactionStrategy.LOCAL).buildModule(),
   new MyApplicationModule());
   addComponentInstantiationListener(new GuiceComponentInjector(this, injector));

   Make sure that you pass your injector into the GuiceComponentInjector constructor, otherwise things dont work later on (this took me several hours to figure out )

5. Follow the rest of Peters instructions
6. But make sure that you put the Warp-Filter before the Wicket-Filter. Putting it after did not work for me, its possible that the warp-persist code has changed between Peter’s post and now, or that wicket-juice causes something to go wrong.
7. Thats it. You can get a guice injected hibernate session like this:

   @Inject Provider<Session> session;
   @Transactional
   public void save(T object)
   {
   session.get().saveOrUpdate(object);
   }

   Wherever you need it.

So now you should have a nice warped guicy wicket app (sorry couldn’t resist)

Next time, integrating dynamic finders.

How to stop non-ajax form submits in wicket

The situation:

You have a form with a single input box and an ajax submit link or button, much like the main search box on google or zoomf.

The problem:

If you type in the input box and press return the form gets submitted automatically. Firefox does this by simulating a click on the first button it finds in the form, which is OK. IE does this by just submitting the form, which is bad as it ruins the functionality of your form. If you have an AjaxSubmitLink rather than button even Firefox cant get it right.

The solution:

Use prototype to intercept the submit event of the form, stop the event, and fire the onclick event of your ajax button/link.

$('formId').observe('submit', function(e){ Event.stop(e); $('submitId').onclick(null);});

A wicketifed solution:

Wrap this up in a wicket behaviour so it can be resued.

import org.apache.wicket.Component;
import org.apache.wicket.behavior.AbstractBehavior;
import org.apache.wicket.markup.html.IHeaderResponse;

public class StopFormSubmitBehaviour extends AbstractBehavior {

private Component submitButton;
private Component form;

public StopFormSubmitBehaviour(Component submitButton)
{
this.submitButton = submitButton;
submitButton.setOutputMarkupId(true);
}

@Override
public void bind(Component component) {
super.bind(component);
component.setOutputMarkupId(true);
this.form = component;
}

@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderOnDomReadyJavascript(getScript());
}

protected String getScript()
{
StringBuilder js = new StringBuilder();
js.append("$('").append(form.getMarkupId()).append("').observe('submit', function(e){
Event.stop(e); $('")
.append(submitButton.getMarkupId()).append("').onclick(null);});");
return js.toString();
}
}

In action:

Form form = new Form("f");
form.add(new TextField("i"));
AjaxSubmitLink b;
form.add(b = new AjaxSubmitLink("b"){
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
}
});
add(form);
form.add(new StopFormSubmitBehaviour(b));