Category Archives: tapestry5

equanda 0.9 released

equanda, a open source project to generate a JEE application based on a domain model, has released version 0.9.

equanda generates the EJB3 access objects with possibility for powerful declarative constraints and added programmatic constraints.
equanda also generates a tapestry5 based user interface with powerful options for customizations.
All this (and quite a few other bots and pieces) are generated at compile time from a XML description of the data and constraints. The customizations remain intact in the generation process.

This is the first usable release of equanda since the project started (though the user interface still lacks features).

Notable changes include :

  • initial tapestry5 user interface
  • type handling in field templates now also interprets subtags
  • filter string per table
  • improved form traversal in user interface, which also auto switches to the next tab
  • allow templates to define extra key-value pairs, possibly overwritten by user
  • fields named “Reference” or “Description” should automatically be marked as is-reference or is-description
  • generate UML and OWL from the domain model
  • Improve xml reading/handling in domain model parsing code
  • add selectors on proxies
  • create archetype for empty equanda project
  • tapestry5 accordion component
  • tapestry5 tabs component
  • tapestry5 FormTraversal component
  • add equandaReset() method in proxies to revert the state to the database values
  • tapestry5 create “manifest” binding prefix
  • Should allow a table type (in the inheritance tree) to be impossible to create

For more information, visit the project web site : http://

“simple” web services using CXF deployed in JBoss

I needed web services up and running, and after a short look at what looks like the best framework for implementing web services, I ended up choosing CXF.

Now though the standalone demo is pretty simple (as explained on the site), deploying this in JBoss is somewhat more difficult. This is partly caused by difficult to find documentation, and partly by possible clashes caused by the classloader (some libraries you really don’t want to have in your classpath twice).

Let’s start by running the demo, then explain what I did and why I made some of the choices I made.

I have a small project which implements this little demo that you can download. You have to fix some of the settings in the main pom.xml file. Specifically the details of your JBoss installation which can be found in the properties in the dev-example profile.
You also need a working JBoss instance, with cargocpc in it. One option is downloading this tuned configuration. I would recommend you to remove the “jbossws.sar” directory from deploy. This contains a different web services stack. However, the demo does not include the CXF libraries, so these need to be added in your deploy directory. The easiest way is to download and extract cxf-2.0.5.sar.tgz.

When these changes are done, thanks to maven, you can run and test the simple “ping” web service by typing
mvn -Dfulltest -Ddev=example install

The actual service and implementation are very simple

package cxfdemo.ws10;

public interface PingService
    String getPing();

package cxfdemo.ws10.impl;

import cxfdemo.ws10.PingService;

import java.sql.Date;

public class PingServiceImpl
    implements PingService
    public String getPing()
        return "Ping back @" + new Date( System.currentTimeMillis() );

To assure this works, the following web.xml is provided

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"


        <display-name>Prolix Web Services 1.0</display-name>


This in turn refers to the following cxf.xml configuration file

<beans xmlns=""

    <import resource="classpath:META-INF/cxf/cxf.xml" />
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

    <simple:server id="ping"
            <bean class="cxfdemo.ws10.impl.PingServiceImpl"/>
            <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding"/>


Running and testing this bean can be done using this simple program.

package cxfdemo.ws10.test;

import cxfdemo.ws10.PingService;
import junit.framework.TestCase;
import org.apache.cxf.frontend.ClientProxyFactoryBean;

public class PingTest
    extends TestCase
    public void testPingService()
        throws Exception
        ClientProxyFactoryBean factory = new ClientProxyFactoryBean();
        factory.setServiceClass( PingService.class );
        factory.setAddress( "http://localhost:8080/cxfdemo/ws/1.0/ping" );
        factory.getServiceFactory().setDataBinding( new AegisDatabinding() );
        PingService client = (PingService) factory.create();
        String res = client.getPing();
        assertTrue( res.startsWith( "Ping back @" ) );

This all is very short and compact.

Why the projects is built like this.

  • The project does not include the libraries as JBoss can cause problems when a library is in the classpath more than once. “commons-logging” is a typical example of this.
    This also has the advantage that the deployments don’t need to include the libraries again.
  • The service interface is put in a separate module than the implementation. This allows easy distribution of the interfaces in java form (which for many people is more readable than wsdl files).
  • The project is built to allow compiling and installing to work without running the full tests. However, you can run them if you want to (using the fulltest profile).
  • There is a jboss web services implementation which uses CXF. However, this was not used here as this does not include the “simple” CXF interface, only the JAX-WS interface.
  • The web services module names, interface packages and URL includes a version identifier. This is part of the the way the project is built. When all the interfaces are in one module, then it should be possible to keep the services stable (same WSDL) even when the actual backend code changes. When incompatible changes are required, you can just create anoth set of modules (one interface, one implementation, and provide the changes there.

equanda-tapestry5, tapestry components easily usable

I have finally made it easy to use the equanda-tapestry5 components. They were already available but required getting the source from svn and compiling. Now you can just download the jar or use the dependency in maven. I have now baked an intermediate version to make it easier to use (without requiring a full equanda release).

These are not components which will make your applications more sexy. For now these are mainly oriented at usability of the tapestry application. More to come later on.

It contains the following components :

  • Accordion :
  • a typical accordion component.

  • Tabs :
  • A Tabs component which integrates nicely with FormTraversal (works perfectly fine without as well).

  • FormTraversal :
  • make the tab and enter keys more consistent, allow submitting default button using and some other nice features.

  • Truncate :
  • shorter a string to something more limited, displaying the full text on mouseover.

  • FormActionLink (and Form) :
  • a form aware version of ActionLink which submits the form so that the state is remembered when you go back.

  • other :
  • there are a few translators (for double which allows both comma and dot as decimal separators) and for timestamp.

More details on the project site.