• Maven2 Webtype Plugin
• Maven2 Stripes-on-Rails Configuration Archetype
• Corresponding Templates
• Other quirks
  • Override default templates
  • Inherit configuration to make new configuration
  • Add webtype to existing projects

Webtype

We ended up calling the project Webtype (as oppose to archetype). A webtype is for now geared towards Java web-based applications. A webtype consists of an architecture configuration and corresponding templates. In the Stripes-on-Rails configuration, it includes dependencies such as Stripes, Spring, Hibernate, EJB3 Annotation, and supporting base classes such as BaseCRUDAction, BaseCRUDManager, BaseDAO to scaffold default CRUD behaviors. It would then use the templates to generate the CRUD features from a domain entity, including JSP pages, Spring configuration, Hibernate configuration, etc.

How to Use?

1. webtype com.acme.example webapp # create a new webapp/ directory with a project structure
2. generate Person # generate CRUD feature and configuration
3. export derby # export database schema to Apache Derby database
4. initdata derby # load initial data from xml into Apache Derby database
5. run # execute the web server
6. http://localhost:9090/webapp/Person.action # view the webapp!

The web server will check for class and JSP updates to hot deploy changes.

Play Nice with Existing Project

Webtype is a generic Maven2 plugin that looks for a webtype.xml descriptor either in the current project or in the classpath. Suppose there is an existing Maven2 project that needed quick code generation, one can easily add the descriptor and the corresponding templates to src/webtype/, that's all! It doesn't really care what architecture you have underneath, so long the generated code works for you.

But sometimes I can't help but to think if we can get any simpler? I say yes we can! How simple can we get? Obviously, from the basic domain entity classes, we should be able to generate at runtime all the things we ever need for basic CRUD operations (including screen, sql). This has been done and that's what made other frameworks (even language) popular. However, we are Java developers. We want to do this while maintaining good multi-teired POJO architecture and its flexibility!

For this, we need to look in to quite a few currently available technology:

1. Spring
2. Stripes
3. Hibernate
4. EJB3
5. Maven2

Spring

What! Wasn't this suppose to be easy? Do we really have to write XML? The answer is of course not! Well, maybe for a few configuration issues. But that's another issue we'll deal with in Maven2 profile. But we do need Spring to tie all the frameworks together while maintaing flexibility in the future when necessary. The default Spring configurations can be encapsulated in a Jar file so that no body really need to edit it for the default behavior. Moreover, we can use Acegi Security for authentication. Of course, this default confdiguration is encapsulated as well.

Stripes

Stripes is a light and simple framework that takes advantages of Java 5 Annotations while keeping away from what I call "annotation hell". With Stripes, we can easily extend its ActionBean and ActionResolver facilities. What this means is that we can creat a GenericCRUDActionBean like:

public interface GenericsCRUDActionBean<T> {

public T getEntity(); // single

public void setEntity(T entity);

public List<T> getEntities(); // multiple entities, such as query results

public setEntities(List<T> entities);

public Resolution save(); // event

public Resolution query(); // event

public Resolution delete(); // event

}

ActionResolver can be used to automatically determine what ActionBean is to be instantiated for a URI request. For example, /context/Person.action will automatically instantiate a new GenericsCRUDActionBean<T> and serve the incoming request.

Moreover, quite remarkable jobs has been done with Stripes form generation by community members that can generate HTML forms from ActionBeans. Associations are also taken into account. We can further extend this to use DOJO widgets for property types such as Date (DOJO date picker). Moroever, we can also generate DOJO validation attributes from Stripes' Validation annotation or other validation oriented annotations.

EJB3

To stay away from XML configuration, we can use EJB3 annotations for entity beans, a.k.a. domain classes. To further staying away from EJB3 descriptors, we can use Hibernate for ORM. Not only that, we dont' even need to write hibernate.cfg.xml to declare what domain classes should be mapped! The reason is that we can resolve EJB3 annotated entity beans the same way Stripes resolve its ActionBeans. Stripes annotation resolver utility can be easily integrated into a new Spring bean that extends AnnotationHibernateSessionFactoryBean.

Hibernate

Generics DAO pattern already exist for Hibernate. Thus, there can be a class GenericsDAO<T> that looks like:

public interface GenericsDAO<T, ID> {

public void save(T entity);

public void findByExample(T example);

public void delete(ID id);
}

What about the Service Layer?

By default, similar GenericsManager<T, ID> can be implemented that delegates to GenericsDAO<T, ID>. Although not strictly necessary, but it may help enforce some architectural consistency if one decided to get away from these Generics stuff. After all, they are generic!

Maven2

Maven2 can help in the overall build, test, and deploy process. Specifically, I'm looking at Maven2 in the following areas:

1. Configuration (profile.xml)
2. Build and Packaging (into deployable WAR file)
3. Dependency (let's see… stripes, hibernate, ejb3, spring, acegisecurity, …)
4. Testing and Reports (All kinds of reports in test results, code quality, documentations, todos, …)
5. Archetype (Who wants to rewrite all these? Create the whole project from the archetype!)
6. Execdution (Jetty6 plugin seems very promising. One can execute a web project using just one command)

Basically, with Maven2, this is what we do to get started:

1. mvn archetype:create ……. (create a new project with all the default pom.xml, directory structure, dependencies, report requirements, site generations, packaging details, and of course, Jetty6 plugin to execute the whole thing for immediate results)
2. Create a domain entity class, e.g. a Person class.
3. mvn jetty6:run (compile and run the application! go to http://localhost:8080/project/Person.action to see it in action)

That should be the MOST that one should need to do. Database generation and initial data loading can be configured to execute at deployment/initialization time. These can also be done via command line such as mvn hibernate:schemaExport, mvn dbunit:loadData (via corresponding plugins).

Now suppose we make this even simpler:

1. createProject com.nooton.webapp my-webapp
2. @Entity public class Person { @Id public Long id; public String name; public String address; }
3. runProject
4. http://localhost:9090/my-webapp/Person.action

That's all.

Abstract DAO

In this architecture, one is free to implement their own DAO, Manager, or ActionBean. We can make the DAO implementation job easier by introducing Abstract DAO annotation from previous idea and implementation. So in case one really needs to do some custom queries, one can annotate the query to an abstract method, rather than getting into Hibernate details (getHibernateTemplate()… throw exceptions…) 

Conclusion

Whew! There are obviously many frameworks that would need to be integrated. But the good news is, most of the integration are probably done daily for a new project based with Spring, Hibernate, and similar tools. While this "framework" can allow quick implementations of simple CRUD web applications, it is based on the entire POJO stack that can be easily extended to the extent that any other similar project structure can extend to. It does not pose any restrictions on the entire application coding "convention". In fact, if one really want to use another framework for any layer, it is possible to completely swap the entire layer out with Spring configuration.

It took me a while to learn a bit about Spring's AOP framework. After hours of struggling with words such as Attribute, Definition, Config, Advisor, Source, ObjectSourceDefinition, I finally realized that those were not the problems.

Apparently Spring AOP can only proxy a real instantiated object, i.e. non-abstract class. But the idea is to use the abstract class and let someone else implement it using information provided with @HQL annotation.

So I switched to CGLIB, setting super class to the abstract class, and intercept calls to abstract methods that are annotated.

This is what I get so far….

DAO Code:

public abstract class PersonDAOHibernate
  extends HibernateDaoSupport
  implements PersonDAO
{
  @HQL("from Person p where p.name = :arg1")
  public abstract List<Person> findByName(String name);
  @HQL("from Person")
  public abstract List<Person> findAll();
}

Because the method argument names are not accessible in compiled code, I had the resolve to naming by argument index numbers (starting from 1). I think I'll also add argument/parameter level annotations that can specify parameter names:

@HQL("from Person p where p.name = :name");
public abstract List findByName(@NamedParam("name") String name);

Right now it recognizes return types of List and of the domain class for select/find operations. For updates, it recognizes return types of void and integer (for returning counts)

The Spring configuration currently looks like the following:

<bean id="personDao"
  class="com.nooton.spring.dao.hibernate3.annotation
    .AnnotationHibernateDAOProxyFactoryBean">
  <property name="targetClass"
    value="dao.hibernate.PersonDAOHibernate"/>
  <property name="sessionFactory"
    ref="sessionFactory"/>
</bean>

/**
  * @ejb.select query="...."
  */
public abstract Collection ejbSelectWithKey(String key)
  throws FinderException;

Although it seems like named queries are to replace the use of this kind of methods. I still enjoyed the fact that the method is, afterall, a Java method. The Java language can provide name, parameter, and type checkings to this method, where named queries can't.

I could imaging something similar w/ Spring and DAO, and some simple AOP/proxy to achieve the following:

public abstract class PersonDAOHibernate implements PersonDAO
{
  @HQL("from Person p where p.id = :id");
  @InitializeProperties({"accounts", "projects"});
  public abstract Person getById(Long id)
    throws DataAccessException;
  @HQL("from Person p where p.age > 20");
  @Paged(pageSize = 10);
  public abstract Pager selectQualifiedAdults()
    throws DataAccessException;
  @HQL("from Person p where p.name like '%:name%'")
  @Paged(pageSize = 15);
  public abstract Pager selectByNameLike(String name)
    throws DataAccessException;
  @HQL(namedQuery="person.ageGreaterThan")
  @Paged
  public abstract Pager selectByAgeGreaterThanPaged(
    Integer age, int pageSize)
    throws DataAccessException;
  @HQL(namedQuery="person.ageGreaterThan")
  @PagedList
  public abstract List selectByAgeGreaterThanList(
    Integer age, int pageSize, int page)
    throws DataAccessException;
  @HQL(namedQuery="person.ageGreaterThan")
  @PagedList
  public abstract PagedList selectByAgeGreaterThanList(
    Integer age, int pageSize, int page)
    throws DataAccessException;
}

Different implementations can use different annotation for the queries e.g. @SQL, @EQL, etc. Not only can it embed a query, it can also link to named queries.

Without the Open Session In View pattern, it is necessary to load all the data that is required in upper tiers callers. There is a feature in XDoclet for EJB 2.0 to generate value objects that does this pretty well. However, in the recent development of ORM, it seems there is a need to manually initialize the lazily-loaded fields for each DAO methods (if not using Open Session In View). In this example, fields initialization can be explicitly specified using @InitializeProperties.

Lastly, when the query string and parameters are known, it can auto-magically create a Pager object, which can dynamically load a page of items when called.

Updated May 13, 2006 – See here