Stephan Schwab - SpringFramework category

Starting to love EJB3 Hibernate Annotations

Fri, 09 Mar 2007 03:24:31 GMT

As our current project allows for some experimentation and adoption of recent technologies, we spent today with EJB3 Hibernate Annotations to get away from the XML configuration one used to create with Hibernate before.

The annotations need to be placed in the same compilation unit as the entity class lives in. The result is that these POJOs now are no longer POJOs in a very tight sense. That has been criticized as polluting the codebase with ORM specific annotations. That's certainly right, but one does not replace one ORM tool for another very often and going with the EJB3 Java Persistence annotation one can replace ORM tools, as Hibernate is just one implementation of that API. So I wouldn't fear too much. After all those classes that become entity classes are meant to be stored into a database and somewhere I have to put the mapping. Doing so in Java code instead of an external XML file appears to be clearer and more appealing to a developer.

Here is something we learned today.

Let's define a persistent entity class called Issue.

@Entity
@Table(name="issue")
@NamedQueries( { @NamedQuery(name = "findIssueById", query = "from Issue i where i.id = ?") })
public class Issue implements IdentifiableObject {

  @Id @GeneratedValue
  private long id ;

[...]
}

This entity will be persisted into the table issue and you see that it has an id field. Other fields are omitted for clarity. Further we define a named query findIssueById.

In a generic DAO class using Spring's Hibernate template we create a method findById as follows.

public Object findById(String query, long id) {
  List list = getHibernateTemplate().findByNamedQuery(query, id);
  if (list.isEmpty())
    return null ;
  else
    return list.get(0) ;
}

Elsewhere in the application we can the find any entity by calling findById passing in the name of the named query and of course the query criteria id.

Issue issueRead = (Issue) repository.findById("findIssueById", someId) ;

In your Spring application context configure your session factory using the AnnotationSessionFactoryBean.

<bean id="mySessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
  <property name="dataSource" ref="myDataSource"/>
  <property name="hibernateProperties">
    <props>
      <prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
      [...]
    </props>
  </property>
  <property name="annotatedClasses">
    <list>
      <value>net.caimito.savila.Issue</value>
    </list>
  </property>
</bean>

Checking a bean's health

Tue, 30 Jan 2007 05:22:53 GMT

Sometimes the little details get overlooked. While I'm working on my book about Acegi Security I read a lot of its source code and that's always a refreshing learning experience. In fact I'd like to recommend anyone to take advantage of open source and take it literally: read the source. It educates and stimulates.

What did I find? Nothing big, but still something I had overlooked in a past project when I wanted to make sure that beans that were vital to the system have been properly initialized. In Spring there is the InitializingBean interface, which defines the afterPropertiesSet() method. Spring will call this method on all beans implementing this interface after it has set the bean's properties.

Now you can use Spring's Assert class to perform checks and have an exception thrown, if something is wrong. It's all built-in and free.

[TSE] Meeting Requirements through Acceptance and Stress Testing

Sun, 10 Dec 2006 13:57:45 GMT

My fellow German developer Eberhard Wolff is speaking this morning about acceptance and stress testing to meet requirements.

As an introduction he's wrapping up what Spring provides in the org.springframework.test package.

Acceptance Tests

Now we are getting into Acceptance Tests. You use them to find errors in the implementation of business requirements or use cases. One can see them as formalized requirements. Unfortunately many times they are done manually and after the whole system has been developed. Fit/FitNesse is a tool for acceptance tests. The customer and the developer should write the acceptance tests together - so does XP say. Fit/FitNesse uses HTML as input format. Test data and expected results are provided as HTML tables. You need to write a simple class as a wrapper for business logic, which can be injected using @Configurable. This class is then used to pass data into the test and check the results.

Eberhard is working on a general Fit Exporter for Spring. It's currently Alpha code.

The SpringActionFixture can be used to test actions that are usually performed in a GUI. You specify input data and actions - e.g. press add button - and then look for results. In the HTML input file you use the expression "press" to call a method. So the UI stuff is left out, but the method that normally be called by the UI is now being called by FitNesse.

One question from the audience is whether you can run Fit/Fitnesse as part of a Maven build. As it's a command line tool that should be no problem.

Fit uses HTML files as input. Fitnesse uses Wiki pages. Triggered by a question from the audience Eberhard opinions that probably Word documents that get exported to HTML are the best solution to get business people to provide test data and rules.

Performance Tests

JMeter is a good tool to performance test web based applications. JMeter creates a large number of requests, but how do you measure the performance in the whole system. You want to measure each part of the system. Using a regular profiler for Java would not be sufficient for the purpose of performance tests, because it only focuses on the Java code itself. JAMon is a monitoring framework, which offers a Spring interceptor. For web application you configure a filter in web.xml. The JAMon filter measures HTTP request/response. JAMon profiles method calls using AOP. JAMon can be used as well to profile other parts of the system by simply declaring other AOP aspects, e.g. you could use it to profile SQL queries.

One could use JAMon even in production as the overhead is very little. It can use exiting Pointcuts and Spring AOP proxies.

[TSE] System Integration Testing with Spring

Sat, 09 Dec 2006 16:43:14 GMT

Fixing defects at a late stage in a project is more costly and causes more pain than doing it as early as possible.

Testable code is good code. Testing is essential to agile processes. AOP helps to isolate concerns. Infrastructure can be left out of the business logic and hence makes testing the business logic easier or - in some cases - possible.

Developers should take ownership of unit and integration tests and not rely on a QA function. A QA function is still needed, but developers should start testing while writing code. Many developers don't test the UI, which is bad. JWebUnit can help with that for web applications.

Rod stresses the importance of performance assurance and regression testing. The Grinder is a free tool for load testing.

Unit testing. Don't use Spring in a unit test. Do use mocks or stubs. Unit tests should run extremely fast. With mock objects you can create expectations. See Easymock or Mockobjects. Mock objects are great for service layer objects and domain objects and to test what happens in the event of a failure. A few things that make testing hard: static methods, final classes. You can't test in isolation: configuration, JDBC code or O/M mapping and how classes work together.

Artifacts to test: service layer, domain objects, special cases such as aspects, web tier code, code containing SQL or other queries and code interacting with J2EE APIs. Non-Java code like stored procedures or triggers, database schema and views. O/R mappings, Spring configuration, JSPs and other view technologies. With Velocity you can test the without being tied to a container.

In-Container testing with tools like Cactus is not the answer.

Spring helps with the org.springframework.test package available in spring-mock.jar since Spring 1.1.1. Provides Spring context loading and caching, transaction management and - of course - dependency injection.

Put things like the datasource and transaction manager declaration in configuration files of their own so you can use different ones for testing and production use.

If you are on Java5 use AbstractAnnotationAwareTransactionalTests for tests.

Use the JDBCTemplate exposed by the abstract classes to verify that the O/RM tool did what it's supposed to do.

Test lazy loading with endTransaction()

startNewTransaction() to test attach/detach in an ORM tool (merge() or saveOrUpdate()). Test locking strategies.

[TSE] The Art of Domain Modeling

Fri, 08 Dec 2006 19:23:38 GMT

Now at the beginning of the afternoon it's Keith Donald's second talk about Domain Driven Design at The Spring Experience.

Effective modeling is about creating a knowledge rich model with everything relevant to the problem being solved. In order to achieve this one has to develop a common language so that everybody involved has a chance to stay on the same page. It's about brainstorming and experimenting using tools such as unit tests and the IDE. The idea is to write code very early, but for the time being leave questions of the infrastructure out.

Domain experts and developers need to work together. Only I believe that most domain experts don't have the time to follow that approach. So in the end it will be about showing a simplistic prototype to them. Something that appears to be working, although underneath there is no functionality that can really be put into production. I see a few questions here.

Once you understand enough of the domain problem, write some code. Focus on behavior, avoid all infrastructure. Then get some feedback from users. Again I see some questions here. The idea is certainly a good one, but will the users accept being shown something that is purely a simulation? Some non-technical people tend to expect real working software dealing with real data at an early stage. So here will be certainly some need to explain things to them.

[TSE] The Building Blocks of Domain Driven Design

Fri, 08 Dec 2006 16:04:58 GMT

Keith Donald's talk at The Spring Experience has started. Right now he's summarizing what Eric told us before.

A domain model does not capture every aspect of the real world. Instead it's a simplistic view of the world to serve a purpose. Discoveries during the implementation feed back into the model design.

Isolate the domain by using a layered architecture. Do not mix UI, database, external services and business objects all together. The very same isolation allows unit testing and Spring helps in the wiring of the units.

Keith shows a diagram with the user interface on top of the application and the application on top of the domain and everything on top of the infrastructure. The application layer delegates tasks to the domain layer for complex solutions.

The domain layer represents business rules and states.

The infrastructure layer interacts with the database, constructs UI widgets and deal with everything technical.

The domain layer is to isolate the domain objects from other functions in the system to avoid mixing technical and domain concepts. One should bind the model the implementation early. Implement the behavior of the application within the domain model classes without thinking about the technical infrastructure. The resulting artifact is a unit test.

In the beginning map domain entities literally to Java objects. Some of these mappings may be wrong in the end and you will need to refactor, but it's a start. Then start writing unit tests using those classes. Keith is now showing actual code of unit tests for his reward dining example.

Organize domain behaviors into coarse-grain, high-level user operations. Make user operations part of the application layer. Unit tests in the domain layer are a good place to look for application layer use-cases. The application layer encapsulates complex domain layer objects and rules and allows for freedom in the implementation. After defining the boundaries of the application layer focus on streamlining the domain model implementation.

Streamline associations between model objects. If you don't understand why an association is needed, avoid it. Association create coupling, which is generally to be avoided. Impose a traversal direction on associations.

Entities, value objects and services. Often entities are persisted to a database. Entities maintain their identity that never changes. Entities may be used by other applications and need to be tracked. They have a life cycle and the model needs to define what it means to be the same thing. String entity objects down to the most intrinsic characteristics and only add required behavior and attributes needed for that behavior. For everything else add associated objects.

Value objects are identified by their attributes and often they are interchangeable and transient. Value objects can be shared and are good candidates for immutability. They reduce bugs by avoiding invariants.

Services are activities or actions, not a thing. A service is something that makes it happen and is stateless. Services should be thin coordinators and one should resist the urge to develop fat services that attempt to solve the problem all on their own. Look for natural opportunities to encapsulate behavior in services that doesn't make sense within Entities or Value Objects. The main responsibility of a service is to orchestrate things, to coordinate. It delegates to entities to do the work.

The creation of Entities should be done using factories and repositories that restore an entity object from a persistent form. Services control and coordinate the life cycle of entities.

Someone asked whether a repository isn't a service. Keith answers is that a repository is a DAO service, but with a very simple job. It doesn't coordinate work and therefore it wouldn't be justified to call it a service.

Make sure that your factories and repositories return fully initialized objects to their callers.