XML validation with imported/included schemas

September 2nd, 2012 2 comments

Recently, I tried to help a teammate design a WSDL file. I gently drove him toward separating the interface itself in the WSDL file and domain objects in a XML Schema file. One thing leading to another, I also made him split this XSD into two separate files, one including another for design purposes. Alas, tests were already present, and they failed miserably after my refactoring, complaining about a type in the included file not being found. The situation was extremely unpleasant, not only because I looked a little foolish in front of one of my co-worker, but also because despite my best efforts, I couldn’t achieve validation.

I finally found the solution, and I hope to spread it as much as I can in order for other developers to stop loosing time regarding this issue. The root of the problem is that the Java XML validation API cannot resolved included XML schemas (and imported ones as well), period. However, it allows for registering a (crude) resolver that can provide the content of the included/imported XSD. So, the solution is to implement your own resolver and your own content holder (there’s none provided in the JDK 6).

  1. Create a “input” implementation. This class is responsible for holding the content of the resolved schema.
    public class LSInputImpl implements LSInput {
    
        private Reader characterStream;
        private InputStream byteStream;
        private String stringData;
        private String systemId;
        private String publicId;
        private String baseURI;
        private String encoding;
        private boolean certifiedText;
    
        // Getters and setters here
    }
  2. Create a resolver implementation. This one is based on the premise that the included/imported schemas lies at the root of the classpath, and is relatively simple. More complex implementations can provide for a variety of locations (filesystem, internet, etc.).
    public class ClasspathResourceResolver implements LSResourceResolver {
    
        @Override
        public LSInput resolveResource(String type, String namespaceURI, String publicId, String systemId, String baseURI) {
    
            LSInputImpl input = new LSInputImpl();
    
            InputStream stream = getClass().getClassLoader().getResourceAsStream(systemId);
    
            input.setPublicId(publicId);
            input.setSystemId(systemId);
            input.setBaseURI(baseURI);
            input.setCharacterStream(new InputStreamReader(stream));
    
            return input;
        }
    }
  3. Finally, just set the resolver on the schema factory:
    SchemaFactory schemaFactory = SchemaFactory.newInstance(W3C_XML_SCHEMA_NS_URI);
    
    schemaFactory.setResourceResolver(new ClasspathResourceResolver());

These 3 steps will go a long way toward cleanly splitting your XML schemas.

Categories: Java Tags: ,

Re-use your test classes across different projects

August 25th, 2012 1 comment

Sometimes, you need to reuse your test classes across different projects. These are two use-cases that I know of:

  • Utility classes that create relevant domain objects used in different modules
  • Database test classes (ans resources) that need to be run in the persistence project as well as the integration test project

Since I’ve seen more than my share of misuses, this article aim to provide an elegant solution once and for all.

Creating the test artifact

First, we have to use Maven: I know that not everyone is a Maven fanboy, but it get the work done – and in our case, it does it easily. Then, we configure the JAR plugin to attach tests. This will compile test classes and copy test resources, and package them in an attached test artifact.

<project>
  <build>
    <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-jar-plugin</artifactId>
       <version>2.2</version>
       <executions>
         <execution>
           <goals>
             <goal>test-jar</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
    </plugins>
  </build>
</project>

The test artifact is stored side-by-side with the main artifact once deployed in the repository. Note that the configured test-jar is bound to the install goal.

Using the test artifact

The newly-created test artifact can be expressed as a dependency of a projet with the following snippet:

<dependency>
  <groupId>ch.frankel.blog.foo</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>
  <type>test-jar</type>
  <scope>test</scope>
</dependency>

The type has to be test-jar instead of simply jar in order to Maven to pick the attached artifact and not the main one. Also, note although you could configure the dependency with a classifier instead of a type, the current documentation warns about possible bugs and favor the type configuration.

To go further:

Categories: Java Tags: ,

Spring Data, Spring Security and Envers integration

August 20th, 2012 3 comments

Spring Data JPA, Spring Security and Envers are libraries that I personally enjoy working with (and I tend to think they are considered best-of-breed in their respective category). Anyway, I wanted to implement what I consider a simple use-case: entities have to be Envers-audited but the revision has to contain the identity of the user that initiated the action. Although it seem simple, I had some challenges to overcome to achieve this. This article lists them and provide a possible solution.

Software architecture

I used Spring MVC as the web framework, configured to use Spring Security. In order to ease my development, Spring Security was configured with the login/password to recognize. It’s possible to connect it to a more adequate backend easily. In the same spirit, I use a datasource wrapper around a driver manager connection on a H2 memory database. This is simply changed by Spring configuration.

A typical flow is handled by my Spring MVC Controller, and passed to the injected service, which manages the Spring Data JPA repository (the component that accesses the database).

Facts

Here are the facts that have proven to be a hindrance (read obstacles to overcome) during this development:

  • Spring Security 3.1.1.RELEASE (latest) uses Spring 3.0.7.RELEASE (not latest)
  • Spring Data JPA uses (wait for it) JPA 2. Thus, you have to parameterize your Spring configuration with LocalContainerEntityManagerFactoryBean, then configure the EntityManager factory bean with the implementation to use (Hibernate in our case). Some passed parameters are portable across different JPA implementations, other address Envers specifically and are thus completely non-portable.
    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="jpaDialect">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
        </property>
    </bean>
    <bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="generateDdl" value="true" />
                <property name="database" value="H2" />
                <property name="showSql" value="true" />
            </bean>
        </property>
        <property name="jpaProperties">
            <props>
                <prop key="org.hibernate.envers.auditTablePrefix"></prop>
                <prop key="org.hibernate.envers.auditTableSuffix">_HISTORY</prop>
            </props>
        </property>
    </bean>
  • Spring Data JPA does provide some auditing capabilities in the form of the Auditable interface. Auditables have createdBy, createdDate, modifiedBy and modifiedDateproperties. Unfortunately, the library doesn’t store previous state of the entities: we do have to use Envers that provide this feature
  • After having fought like mad, I realized integrating Envers in Spring Data JPA was no small potatoes and stumbled upon the Spring Data Envers module, which does exactly that job. I did founf no available Maven artifacts in any repository, so I cloned the Git repo and built the current version (0.1.0.BUILD-SNAPSHOT then). It provided me with the opportunity to give a very modest contribution to the project.

On the bright side, and despite all examples I googled, the latest versions of Hibernate not only are shipped with Envers, but there’s no configuration needed to register Envers listeners, thanks to a smart service provider use. You only need to provide the JAR on the classpath, and the JAR itself takes care of registration. This makes Envers integration much simpler.

How to

Beyond adding Spring Data Envers, there’s little imagination to have, as it’s basic Envers use.

  • Create a revision entiy that has the needed attribute (user):
    @RevisionEntity(AuditingRevisionListener.class)
    @Entity
    public class AuditedRevisionEntity extends DefaultRevisionEntity {
    
        private static final long serialVersionUID = 1L;
    
        private String user;
    
        public String getUser() {
    
            return user;
        }
    
        public void setUser(String user) {
    
            this.user = user;
        }
    }
  • Create the listener to get the identity from the Spring Secuirty context and set is on the revision entity:
    public class AuditingRevisionListener implements RevisionListener {
    
        @Override
        public void newRevision(Object revisionEntity) {
    
            AuditedRevisionEntity auditedRevisionEntity = (AuditedRevisionEntity) revisionEntity;
    
            String userName = SecurityContextHolder.getContext().getAuthentication().getName();
    
            auditedRevisionEntity.setUser(userName);
        }
    }

Presto, you’re done…

Bad news

… Aren’t you? The aforementioned solution works perfectly when writing to the database. The rub comes from trying to get the information once it’s there, because the Spring Data API doesn’t allow that (yet?). So, there are basically three options (assuming you care about retrieval: this kind of information may not be for the user to see, and you can always connect to the database to query when -if – you need to access the data):

  • Create code to retrieve the data. Obviously, you cannot use Spring Data JPA (your entity is missing the userfield, it’s “created” at runtime). The best way IMHO would be to create a listener that get data on read queries for the audited entity and returns an enhanced entity. Performance as well as design considerations aren’t in favor of this one.
  • Hack the API, using reflection that make it dependent on internals of Spring Data. This is as bad an option as the one before, but I did it for educational purposes:
    Revisions revisions = stuffRepository.findRevisions(stuff.getId());
    
    List auditedRevisionEntities = new ArrayList();
    
    for (Revision revision : revisions.getContent()) {
    
        Field field = ReflectionUtils.findField(Revision.class, "metadata");
    
        // Oh, it's ugly!
        ReflectionUtils.makeAccessible(field);
    
        @SuppressWarnings("rawtypes")
        RevisionMetadata metadata = (RevisionMetadata) ReflectionUtils.getField(field, revision);
    
        AuditedRevisionEntity auditedRevisionEntity = (AuditedRevisionEntity) metadata.getDelegate();
    
        // Do what your want with auditedRevisionEntity...
    }
  • Last but not least, you can contribute to the code of Spring Data. Granted, you’ll need knowledge of the API and the internals, skills and time, but it’s worth it :-)

Conclusion

Integrating heterogeneous libraries is hardly a walkover. In the case of Spring Data JPA and Envers, it’s as easy as pie thanks to the Spring Data Envers library. However, if you need to make your audit data accessible, you need to integrate further.

The sources for this article are here, in Eclipse/Maven format.

To go further:

Method injection with Spring

July 29th, 2012 3 comments

Spring core comes out-of-the-box with two scopes: singletons and prototypes. Singletons implement the Singleton pattern, meaning there’s only a single instance at runtime (in a JVM). Spring instantiate them during context creation, caches them in the context, and serves them from the cache when needed (or something like that). Prototypes are instantiated each time you access the context to get the bean.

Problems arise when you need to inject a prototype-scoped bean in a singleton-scoped bean. Since singletons are created (and then injected) during context creation: it’s the only time the Spring context is accessed and thus prototype-scoped beans are injected only once, thus defeating their purpose.

In order to inejct prototypes into singletons, and side-by-syde with setter and constructor injection, Spring proposes another way for injection, called method injection. It works in the following way: since singletons are instantiated at context creation, it changes the way prototype-scoped are handled, from injection to created by an abstract method. The following snippet show the unsuccessful way to achieve injection:

public class Singleton {

    private Prototype prototype;

    public Singleton(Prototype prototype) {

        this.prototype = prototype;
    }

    public void doSomething() {

        prototype.foo();
    }

    public void doSomethingElse() {

        prototype.bar();
    }
}

The next snippet displays the correct code:

public abstract class Singleton {

    protected abstract Prototype createPrototype();

    public void doSomething() {

        createPrototype().foo();
    }

    public void doSomethingElse() {

        createPrototype().bar();
    }
}

As you noticed, code doesn’t specify the createPrototype() implementation. This responsibility is delegated to Spring, hence the following needed configuration:

<bean id="prototype" class="ch.frankel.blog.Prototype" scope="prototype" />

<bean id="singleton" class="sample.MySingleton">
	<lookup-method name="createPrototype" bean="prototype" />
</bean>

Note that an alternative to method injection would be to explicitly access the Spring context to get the bean yourself. It’s a bad thing to do since it completely defeats the whole Inversion of Control pattern, but it works (and is essentially the only option when a nasty bug happens on the server – see below).

However, using method injection has several main limitations:

  • Spring achieves this black magic by changing bytecode. Thus, you’ll need to have the CGLIB libraryon the classpath.
  • The feature is only available by XML configuration, no annotations (see this JIRAfor more information)
  • Finally, some application servers have bugs related to CGLIB (such as this one)

To go further:

Transaction management: EJB3 vs Spring

July 22nd, 2012 1 comment

Transaction management is a subject that is generally left to the tender care of a senior developer (or architect). Given the messages coming from soem actors of the JavaEE community that with newer versions of JavaEE you don’t need Spring anymore, I was interested in some fact-checking on how transaction management was handled in both technologies.

Note: these messages were already sent one year and a half ago and prompted me to write this article.

Transaction demarcation

Note that although both technologies provide programmatic transaction demarcation (start transaction then commit/rollback), we’ll focus on declarative demarcation since they are easier to use in real life.

In EJB3, transactions are delimited by the @TransactionAttribute annotation. The annotation can be set on the class, in which case every method will have the transactional attribute, or per method. Annotation at the method level can override the annotation at the class level. Annotations are found automatically by the JavaEE-compliant application server.

In Spring, the former annotation is replaced by the proprietary @Transactional annotation. The behaviour is exactly the same (annotation at method/class level and possibility of overriding). Annotations can only be found when the Spring bean definition file contains the http://www.springframework.org/schema/tx namespace as well as the following snippet:

<tx:annotation-driven />

Alternatively, both technologies provide an orthogonal way to set transaction demarcation: in EJB3, one can use the EJB JAR deployment descriptor (ejb-jar.xml) while in Spring, any Spring configuration file will do.

Transactions propagation

In EJB3, there are exactly 6 possible propagation values: MANDATORY, REQUIRED (default), REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED and NEVER.

Spring adds support for NESTED (see below).

Nested transactions

Nested transactions are transactions that are started then commited/rollbacked during the execution of the root transaction. Nested transaction results are limited to the scope of this transaction only (it has no effect on the umbrella transaction).

Nested transactions are not allowed in EJB3; they are in Spring.

Read-only transaction

Read-only transactions are best used with certain databases or ORM frameworks like Hibernate. In the latter case, Hibernate optimizes sessions so that they never flush (i.e. never push changes from the cache to the underlying database).

I haven’t found a way (yet) to qualify a transaction as read-only in EJB3 (help welcome). In Spring, @Transactional has a readOnly parameter to implement read-only transactions:

@Transactional(readOnly = true)

Local method calls

In local method calls, a bean’s method A() calls another method B() on the same instance. The expected behavior should be that transaction attributes of method B() is taken into account. It’s not the case in neither technologies, but both offer some workaround.

In EJB3, you have to inject an instance of the same class and call the method on this instance in order to use transaction attributes. For example:

@Stateless
public MyServiceBean implements MyServiceLocal {

    @EJB
    private MyServiceLocal service;

    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public void A() {

        service.B();
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void B() {

        ...
    }
}

In Spring, by default, transaction management is handled through pure Java proxies. If you want to have transaction management in local method calls, you’ll have to turn on AspectJ. This is easily done in the Spring beans definition file (but beware the side-effects, see the Spring documentation for more details):

<tx:annotation-driven mode="aspectj" />

Exception handling and rollback

Exception handling is the area with the greater differences between Spring and EJB3.

In EJB3, only runtime exceptions thrown from a method rollback a transaction delimited around this method by default. In order to mimic this behavior for checked exceptions, you have to annotate the exception class with @ApplicationException(rollback = true). Likewise, if you wish to discard this behavior for runtime exceptions, annotate your exception class with @ApplicationException(rollback = false).

This has the disadvantage of not being able to use the same exception class to rollback in a method and to still to commit despite the exception in another method. In order to achieve this, you have to manage your transaction programmatically:

@Stateless
public MyServiceBean implements MyServiceLocal {

    @Resource
    private SessionContext context;

    public void A() {

        try {

            ...

        } catch (MyException e) {

            context.setRollbackOnly();
        }
    }
}

In Spring, runtime exceptions also cause transaction rollback. In order to change this behavior, use the rollbackFor or noRollbackFor attributes of @Transactional:

public MyServiceImpl {

    @Resource
    private SessionContext context;

	@Transactional(rollbackFor = MyException.class)
    public void A() {

		...
    }
}

Conclusion

There’s no denying that JavaEE has made giant steps in the right direction with its 6th version. And yet, small details keep pointing me toward Spring. If you know only about one – Spring or JavaEE 6, I encourage you to try “the other” and see for yourself which one you’re more comfortable with.

To go further:

Categories: JavaEE Tags: , ,

Empower your CSS in your Maven build

July 8th, 2012 No comments

People who know me also know I’ve interest in the GUI: that means I’ve sometimes to get my hands dirty and dig deep into stylesheets (even though I’ve no graphical skill whatsoever). When it happens, I’ve always questions regarding how to best factorize styles. In this regard, the different CSS versions are lacking, because they were not meant to be managed by engineers. A recent trend is to generate CSS from a source, which brings some interesting properties such as nesting, variables, mixins, inheritance and others. Two examples of this trend are LESS and SASS.

A not-so-quick example can be found just below.

Given that I’m an engineer, the only requirement I have regarding those technologies is that I can generate the final CSS during my build in an automated and reproductible way. After a quick search, I became convinced to use wro4j. Here are the reasons why, in a simple use-case.

Maven plugin

Wro4j includes a Maven plugin. In order to call it in the build, just add it to your POM:

<plugin>
	<groupId>ro.isdc.wro4j</groupId>
	<artifactId>wro4j-maven-plugin</artifactId>
	<version>1.4.6</version>
	<executions>
		<execution>
			<goals>
				<goal>run</goal>
			</goals>
			<phase>generate-resources</phase>
		</execution>
	</executions>
</plugin>

You’re allergic to Maven? No problem, a command-line tool is also provided, free of charge.

Build time generation

For evident performance reasons, I favor build time generation instead of runtime. But if you prefer the latter, there’s a JavaEE filter ready just for that.

Configurability

Since wro4j original strategy is runtime generation, default configuration files are meant to be inside the archive. However, this can easily tweaked by setting some tags in the POM:

<configuration>
	<wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>
	<wroFile>${basedir}/src/main/config/wro.xml</wroFile>
	<extraConfigFile>${basedir}/src/main/config/wro.properties</extraConfigFile>
</configuration>

The final blow

The real reason to praise wro4j is that LESS generation is only a small part of its features: for wro4j, it’s only a processor among others. You’ve only to look at the long list of processors (pre- and post-) available to want to use them ASAP. For example, wro4j also wraps a JAWR processor (a bundling and minifying product I’ve blogged about some time ago).

Once you get there, however, a whole new universe opens before your eyes, since you get processors for:

  • Decreasing JavaScript files size by minifying them with Google, YUI, JAWR, etc.
  • Decreasing CSS files size by minifying them
  • Minimizing the number of requests by merging your JavaSscript files into a single file
  • Minimizing the number of requests by merging your CSS files into a single file
  • Processing LESS CSS
  • Processing SASS CSS
  • Analyzing your JavaScript with LINT

The list is virtually endless, you should really have a look. Besides, you can bridge your favorite by writing your own processor if the need be.

Quick how-to

In order to set up wro4j real quick, here are some ready to use snippets:

  • The Maven POM, as seen above
    <plugin>
    	<groupId>ro.isdc.wro4j</groupId>
    	<artifactId>wro4j-maven-plugin</artifactId>
    	<version>1.4.6</version>
    	<configuration>
    		<wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>
    		<wroFile>${basedir}/src/main/config/wro.xml</wroFile>
    		<extraConfigFile>${basedir}/src/main/config/wro.properties</extraConfigFile>
    		<targetGroups>all</targetGroups>
    		<cssDestinationFolder>${project.build.directory}/${project.build.finalName}/style/</cssDestinationFolder>
    		<jsDestinationFolder>${project.build.directory}/${project.build.finalName}/script/</jsDestinationFolder>
    		<contextFolder>${basedir}/src/main/webapp/</contextFolder>
    		<ignoreMissingResources>false</ignoreMissingResources>
    	</configuration>
    	<executions>
    		<execution>
    			<goals>
    				<goal>run</goal>
    			</goals>
    			<phase>generate-resources</phase>
    		</execution>
    	</executions>
    </plugin>

    Note the use of the ConfigurableWroManagerFactory. It makes adding and removing processors a breeze by updating the following file.

  • The wro.properties processors file, that list processings that should be executed on the source files. Here, we generate CSS from LESS, resolve imports to have a single file and minify both CSS (with JAWR) and JavaScript:
    preProcessors=lessCss,cssImport
    postProcessors=cssMinJawr,jsMin
  • The wro.xml configuration file, to tell wro4j how to merge CSS and JS files. In our case, styles.css will be merged into all.css and global.js into all.js.
    <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
    <groups xmlns=&quot;http://www.isdc.ro/wro&quot;>
      <group name=&quot;all&quot;>
        <css>/style/styles.css</css>
        <js>/script/global.js</js>
      </group>
    </groups>
  • Finally, a LESS example can be found just below.

Conclusion

There are some paths to optimization for webapps readily available. Some provide alternative ways to define your CSS, some minify your CSS, some your JS, other merge those files together, etc. It would be a shame to ignore them because they can be a real asset in heavy-load scenarii. wro4j provides an easy way to wrap all those operations into a reproductible build.

LESS
@default-font-family: Helvetica, Arial, sans-serif;

@default-radius: 8px;

@default-color: #5B83AD;
@dark-color: @default-color - #222;
@light-color: @default-color + #222;

.bottom-left-rounded-corners (@radius: @default-radius) {
	.rounded-corners(0, 0, @radius, 0)
}

.bottom-right-rounded-corners (@radius: @default-radius) {
	.rounded-corners(0, 0, 0, @radius)
}

.bottom-rounded-corners (@radius: @default-radius) {
	.rounded-corners(0, 0, @radius, @radius)
}

.top-left-rounded-corners (@radius: @default-radius) {
	.rounded-corners(@radius, 0, 0, 0)
}

.top-right-rounded-corners (@radius: @default-radius) {
	.rounded-corners(0, @radius, 0, 0)
}

.top-rounded-corners (@radius: @default-radius) {
	.rounded-corners(@radius, @radius, 0, 0)
}

.rounded-corners(@top-left: @default-radius, @top-right: @default-radius, @bottom-left: @default-radius, @bottom-right: @default-radius) {
	-moz-border-radius: @top-left @top-right @bottom-right @bottom-left;
	-webkit-border-radius: @top-left @top-right @bottom-right @bottom-left;
	border-radius: @top-left @top-right @bottom-right @bottom-left;
}

.default-border {
	border: 1px solid @dark-color;
}

.no-bottom-border {
	border-bottom: 0;
}

.no-left-border {
	border-left: 0;
}

.no-right-border {
	border-right: 0;
}

body {
	font-family: @default-font-family;
	color: @default-color;
}

h1 {
	color: @dark-color;
}

a {
	color: @dark-color;
	text-decoration: none;
	font-weight: bold;

	&amp;:hover {
		color: black;
	}
}

th {
	color: white;
	background-color: @light-color;
}

td, th {
	.default-border;
	.no-left-border;
	.no-bottom-border;
	padding: 5px;

	&amp;:last-child {
		.no-right-border;
	}
}

tr:first-child {

	th:first-child {
		.top-left-rounded-corners;
	}

	th:last-child {
		.top-right-rounded-corners;
	}

	th:only-child {
		.top-rounded-corners;
	}
}

tr:last-child {

	td:first-child {
		.bottom-left-rounded-corners;
	}

	td:last-child {
		.bottom-right-rounded-corners;
	}

	td:only-child {
		.bottom-rounded-corners;
	}
}

thead tr:first-child th, thead tr:first-child th {
	border-top: 0;
}

table {
	.rounded-corners;
	.default-border;
	border-spacing: 0;
	margin: 5px;
}
Generated CSS
.default-border {
	border: 1px solid #39618b;
}

.no-bottom-border {
	border-bottom: 0;
}

.no-left-border {
	border-left: 0;
}

.no-right-border {
	border-right: 0;
}

body {
	font-family: Helvetica, Arial, sans-serif;
	color: #5b83ad;
}

h1 {
	color: #39618b;
}

a {
	color: #39618b;
	text-decoration: none;
	font-weight: bold;
}

a:hover {
	color: black;
}

th {
	color: white;
	background-color: #7da5cf;
}

td,th {
	border: 1px solid #39618b;
	border-left: 0;
	border-bottom: 0;
	padding: 5px;
}

td:last-child,th:last-child {
	border-right: 0;
}

tr:first-child th:first-child {
	-moz-border-radius: 8px 0 0 0;
	-webkit-border-radius: 8px 0 0 0;
	border-radius: 8px 0 0 0;
}

tr:first-child th:last-child {
	-moz-border-radius: 0 8px 0 0;
	-webkit-border-radius: 0 8px 0 0;
	border-radius: 0 8px 0 0;
}

tr:first-child th:only-child {
	-moz-border-radius: 8px 8px 0 0;
	-webkit-border-radius: 8px 8px 0 0;
	border-radius: 8px 8px 0 0;
}

tr:last-child td:first-child {
	-moz-border-radius: 0 0 0 8px;
	-webkit-border-radius: 0 0 0 8px;
	border-radius: 0 0 0 8px;
}

tr:last-child td:last-child {
	-moz-border-radius: 0 0 8px 0;
	-webkit-border-radius: 0 0 8px 0;
	border-radius: 0 0 8px 0;
}

tr:last-child td:only-child {
	-moz-border-radius: 0 0 8px 8px;
	-webkit-border-radius: 0 0 8px 8px;
	border-radius: 0 0 8px 8px;
}

thead tr:first-child th,thead tr:first-child th {
	border-top: 0;
}

table {
	-moz-border-radius: 8px 8px 8px 8px;
	-webkit-border-radius: 8px 8px 8px 8px;
	border-radius: 8px 8px 8px 8px;
	border: 1px solid #39618b;
	border-spacing: 0;
	margin: 5px;
}
Categories: JavaEE Tags: ,

Easier JPA with Spring Data JPA

July 1st, 2012 2 comments

Database access in Java went through some steps:

  • at first, pure JDBC
  • proprietary frameworks
  • standards such as EJB Entities and JDO
  • OpenSource frameworks such as Hibernate and EclipseLink (known as TopLink at the time)

When JPA was finally released, it seemed my wishes came true. At last, there was a standard coming from the trenches to access databases in Java

Unfortunately, JPA didn’t hold its promises when compared to Hibernate: for example, you don’t have Query by Example. Even worse, in its first version, JPA didn’t provide simple features like Criteria, so that even simple queries would have to be implemented through JPQL and thus achieved with String concatenation. IMHO, this completely defeated ORM purposes.

JPA2 to the rescue

At last, JPA2 supplies something usable in a real-world application. And yet, I feel there’s still so much boilerplate code to write a simple CRUD DAO:

public class JpaDao {

    @PersistenceContext
    private EntityManager em;

    private Class managedClass;

    private JpaDao(Class managedClass) {

        this.managedClass = managedClass;
    }

    public void persist(E entity) {

        em.persist(entity);
    }

    public void remove(E entity) {

        em.remove(entity);
    }

    public E findById(PK id) {

        return em.find(managedClass, id);
    }
}

Some would (and do) object that in such a use-case, there’s no need for a DAO: the EntityManager just needs to be injected in the service class and used directly. This may be a relevant point-of-view, but only when there’s no query for as soon as you go beyond that, you need to separate between data access and business logic.

Boilerplate code in JPA2

Two simple use-cases highlight the useless boilerplate code in JPA 2: @NamedQuery and simple criteria queries. In the first case, you have to get the handle on the named query through the entity manager, then set potential parameters like so:

Query query = em.createNamedQuery("Employee.findHighestPaidEmployee");

In the second, you have to implement your own query with the CriteriaBuilder:

CriteriaBuilder builder = em.getCriteriaBuilder();

CriteriaQuery query = builder.createQuery(Person.class);

Root fromPerson = query.from(Person.class);

return em.createQuery(query.select(fromPerson)).getResultList();

IMHO, these lines of code bring nothing to the table and just clutter our own code. By chance, some time ago, I found project Hades, a product which was based on this conclusion and wrote simple code for you.

Spring Data JPA

Given the fate of some excellent OpenSource projects, Hades fared much better since it has been brought into the Spring ecosystem under the name Spring Data JPA. Out of the box, SDJ provides DAOs that have advanced CRUD features. For example, the following interface can be used as-is:

public interface EmployeeRepository extends JPARepository

Given some Spring magic, an implementation will be provided at runtime with the following methods:

  • void deleteAllInBatch()
  • void deleteInBatch(Iterable<Employee> entities)
  • List<Employee> findAll()
  • List<Employee> findAll(Sort sort)
  • void flush()
  • <S extends Employee> List<S> save(Iterable<S> entities)
  • Employee saveAndFlush(Employee entity)
  • Page<Employee> findAll(Pageable pageable)
  • Iterable<Employee> findAll(Sort sort)
  • long count()
  • void delete(ID id)
  • void delete(Iterable<? extends Employee> entities)
  • void delete(Employee entity)
  • void deleteAll()
  • boolean exists(Long id)
  • Iterable<Employee> findAll()
  • Iterable<Employee> findAll(Iterable ids)
  • Employee findOne(Long id)
  • <S extends Employee> Iterable<S> save(Iterable<S> entities)
  • <S extends Employee> S save(S entity)

Yes, SDJ provides you with a generic DAO, like so many frameworks around but here, wiring into the underlying implementation is handled by the framework, free of charge. For those that don’t need them all and prefer the strict minimum, you can also use the following strategy, where you have to choose the methods from the list above (and use the annotation):

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {

    long count();

    Employee save(Employee employee);
}

It sure is nice, but the best is yet to come. Remember the two above use-cases we had to write on our own? The first is simply handled by adding the unqualified query name to the interface like so:

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {

    ...

    Employee findHighestPaidEmployee();
}

The second use-case, finding all employees, is provided in the JPA repository. But let’s pretend for a second we have a WHERE clause, for example on the first name. SDJ is capable of handling simple queries based on the method name:

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {

    ...

    List findByLastname(String firstName);
}

We had to code only an interface and its methods: no implementation code nor metamodel generation was involved! Don’t worry, if you need to implement some complex queries, SDJ let you wire your own implementation.

Conclusion

If you’re already a Spring user, Spring Data JPA is really (really!) a must. If you’re not, you’re welcome to test it to see its added value by yourself. IMHO, SDJ is one of the reason JavaEE has not killed Spring yet: it bridged the injection part, but the boilerplate code is still around every corner.

This article is not a how-to but a teaser to let you into SDJ. You can find the sources for this article here, in Maven/Eclipse format.

To go further:

For those that aren’t into JPA yet, there’s Data JDBC; for those that are well beyond that (think Big Data); there’s a Data Hadoop. Check all of Spring Data projects!

Categories: Java Tags: , ,

How to test code that uses Envers

June 24th, 2012 3 comments

Envers is a Hibernate module that can be configured to automatically audit changes made to your entities. Each audited entity are thus associated with a list of revisions, each revision capturing the state of the entity when a change occurs. There is however an obstacle I came across while I was “unit testing” my DAO, and that’s what I want to share to avoid others to fall in the same pit.

First, let’s have an overview of the couple of steps needed to use Envers:

  • Annotate your entity with the @Audited annotation:
    @Entity
    @Audited
    public class Person {
    
        // Properties
    }
  • Register the Envers AuditEventListener in your Hibernate SessionFactory through Spring:
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="packagesToScan" value="ch.frankel.blog.envers.entity" />
        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.dialect">org.hibernate.dialect.H2Dialect</prop>
            </props>
        </property>
        <property name="schemaUpdate" value="true" />
        <property name="eventListeners">
            <map>
                <entry key="post-insert" value-ref="auditListener" />
                <entry key="post-update" value-ref="auditListener" />
                <entry key="post-delete" value-ref="auditListener" />
                <entry key="pre-collection-update" value-ref="auditListener" />
                <entry key="pre-collection-remove" value-ref="auditListener" />
                <entry key="post-collection-recreate" value-ref="auditListener" />
            </map>
        </property>
    </bean>
    
    <bean id="auditListener" class="org.hibernate.envers.event.AuditEventListener" />
  • Configure the Hibernate transaction manager as your transaction manager. Note auditing won’t be triggered if you use another transaction manager (DataSourceTransactionManager comes to mind):
    <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
            <property name="sessionFactory" ref="sessionFactory" />
    </bean>
  • Now is the time to create your test class:
    @ContextConfiguration("classpath:spring-persistence.xml")
    @TransactionConfiguration(defaultRollback = false)
    public class PersonDaoImplTest extends AbstractTransactionalTestNGSpringContextTests {
    
        @Autowired
        private PersonDao personDao;
    
        @BeforeMethod
        protected void setUp() {
    
            // Populate database
        }
    
        @Test
        public void personShouldBeAudited() {
    
            Person person = personDao.get(1L);
    
            person.setFirstName("Jane");
    
            List<Person> history = personDao.getPersonHistory(1L);
    
            assertNotNull(history);
            assertFalse(history.isEmpty());
            assertEquals(history.size(), 1);
        }
    }

Strangely, when you execute the previous test class, the test method fails when checking the list is not empty: it is, meaning there’s no revision associated with the entity. Morevoer, nothing shows up in the log. However, the revision shows up in the audited table at the end of the test (provide you didn’t clear the table after its execution).

Comes the dreaded question: why? Well, it seems Hibernate post-event listeners are only called when the transaction is commited. In our case, it matches: the transaction is commited by Spring after method completion, and our test trie to assert inside the method.

In order for our test to pass, we have to manually manage a transaction inside our method, to commit the update to the database.

@Test
public void personShouldBeAuditedWhenUpdatedWithManualTransaction() {

    PlatformTransactionManager txMgr = applicationContext.getBean(PlatformTransactionManager.class);

	// A new transaction is required, the wrapping transaction is for Envers
    TransactionStatus status = txMgr.getTransaction(new DefaultTransactionDefinition(PROPAGATION_REQUIRES_NEW));

    Person person = personDao.get(1L);

    person.setFirstName("Jane");

    txMgr.commit(status);

    List<Person> history = personDao.getPersonHistory(1L);

    assertNotNull(history);
    assertFalse(history.isEmpty());
    assertEquals(history.size(), 1);
}

On one hand, the test passes and the log shows the SQL commands accordingly. On the other hand, the cost is the additional boilerplate code needed to make it pass.

Of course, one could (should?) question the need to test the feature in the first place. Since it’s a functionality brought by a library, the reasoning behind could be that if you don’t trust the library, don’t use it at all. In my case, it was the first time I used Envers, so there’s no denying I had to build the trust between me and the library. Yet, even with trusted libraries, I do test specific cases: for example, when using Hibernate, I create test classes to verify that complex queries get me the right results. As such, auditing qualifies as a complex use-case whose misbehaviors I want to be aware of as soon as possible.

You’ll find the sources for this article here, in Maven/Eclipse format.

Categories: Java Tags: , ,

Vagrant your Drupal

June 17th, 2012 No comments

In one of my recent post, I described how I used VMWare to create a Drupal I could play with before deploying updates to morevaadin.com. Then, at Devoxx France, I attended a session where the talker detailed how he set up a whole infrastructure for after work formations with Vagrant.

Meanwhile, a little turn of fate put me in charge of some Drupal projects and I had to get better at it… fast. I put my hands on the Definitive Guide to Drupal 7 that talks about Drupal use with Vagrant. This was definitely too much: I decided to take on this opportunity to automatically manage my own Drupal infrastructure. These are the steps I followed and the lessons I learned. Note my host OS is Windows 7 :-)

Download VirtualBox

Oracle’s VirtualBox is the format used by Vagrant. Go on their download page and choose your pick.

Download Vagrant

Vagrant download page is here. Once installed on your system, you should put the bin directory on your PATH.

Now, get the Ubuntu Lucyd Linx box ready with:

vagrant box add base http://files.vagrantup.com/lucid32.box

This download the box in your %USER_HOME%/.vagrant.d/boxes under the lucid32 folder (at least on Windows).

Get Drupal Vagrant project

Download the current version of Drupal Vagrant and extract it in the directory of your choice. Edit the Vagrantfile according to the following guidelines:

config.vm.box = "lucid32" // References the right box
...
config.vm.network :hostonly, "33.33.33.10" // Creates a machine with this IP

Then, boot the virtual box with vagrant up and let Vagrant take care of all things (boot the VM, get the necessary applications, configure all, etc.).

Update your etc/hosts file to have the 2 following domains pointing to 33.33.33.10.

33.33.33.10	drupal.vbox.local
33.33.33.10		dev-site.vbox.local

At the end of the process (it could be a lenghty one), browsing on your host system to http://drupal.vbox.local/install.php should get you the familiar Drupal installation screen. You’re on!

SSH into the virtual box

Now is time to get into the host system, with vagrant ssh.

If on Windows, here comes the hard part. Since there’s no SSH utility out-of-the-box, you have to get one. Personally, I used PuTTY. Not the VM uses a SSH key for authentication and unfortunately, the format of Vagrant’s provided key is not compatible with PuTTY so that we have to use PuTTYGen to translate %USER_HOME%/.vagrant.d/insecure_private_key into a format PuTTY is able to use. When done, connect with PuTTY on the system (finally).

Conclusion

All in all, this approach works alright, altough Drush is present in /usr/share/drush but doesn’t seem to work (Git is installed and works fine).

Note: I recently stumbled upon this other Drupal cookbook but it cannot be used as is. Better DevOps than me can probably fix it.

Categories: Development Tags: , ,

Ways of comparing Date objects in Java

June 3rd, 2012 3 comments

Let’s face it, compairing Date objects in Java is complex and as well as error-prone. This is the case in standard code, but this is also the case in testing code, where we regularly need to create Date objects that point at specific instant in time, to be our reference in comparison.

The good ol’ deprecated way

In test code, I’ve no qualms about using deprecated methods. So, I used the old Date constructor to initialize dates:

Date date = new Date(112, 5, 3);

Pro: it’s concise. Con: it really isn’t intuitive and you need a good knowledge of the Java API to know the first parameter is the year minus 1900 and the second is the month count (beginning at 0, for January). It’s almost a surprise to learn the last parameter is simply… the day of the month.

The canonical way

Since Java 1.1, Calendar was introduced in the Java API to dissociate between an instant in time (the date) and its view in a specific referential (the calendar). The following snippet is a naive way to obtain the same result as above.

Calendar calendar = Calendar.getInstance();

calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);

It’s not only more verbose, it’s also a mistake: hours, minutes and the rest are not 0 (depending on the exact creation time of the calendar) so using equals() here will return false. Here’s the correct code:

Calendar calendar = Calendar.getInstance();

calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar.set(HOUR_OF_DAY, 0);
calendar.set(MINUTE, 0);
calendar.set(SECOND, 0);
calendar.set(MILLISECOND, 0);

It defeats brevity purpose, to say the least ;-)

Apache Commons Lang

Apache Commons provides since ages different utility libraries that help develop in Java. One of such library is Apache Commons Lang, which aims at providing code that would merit being part of the Java API.

In our case, the DateUtils class let us shorten the previous code, while keeping its readibility:

Calendar calendar = Calendar.getInstance();

calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar = DateUtils.truncate(calendar, DAY_OF_MONTH);

Even better, DateUtils let us work directly on Date objects, to make the following alternative also possible:

Date date = new Date();

date = DateUtils.setYears(date, 2012);
date = DateUtils.setMonths(date, JUNE);
date = DateUtils.setDays(date, 3);
date = DateUtils.truncate(date, DAY_OF_MONTH);

Note that it leaves parameters untouched, enforcing the immutability dear to Functional Programing proponents. Pro: we use the standard Java API. Con: none. And yet, wouldn’t a full-fledged DSL feel somewhat more right?

Joda Time

The final option is to use Joda Time, which aims at being a replacement for Date and Calendar. It also has spawned the JSR-310“a new and improved date and time API for Java”, that should be part of Java 8 (it was originally scheduled for Java 7). A whole article (or even a mini-guide) could be dedicated to Joda Time. For our present concern, the following snippet can advantageously replace our original one:

DateMidnight dm = new DateMidnight(2012, 6, 3);

Back to square one, it seems: clear and concise. And yet, the parameters self explanatory, no real need to regularly check the JavaDocs to see how to initialize the year. Besides, the semantics of the class name are clear. Finally, the toDate() method let us bridge to the standard Java API.

Conclusion

The conclusion is your own. As for myself, I regularly use Apache Commons Lang, but I’m leaning toward Joda Time these days.

The code is available here as a Eclipse/Maven project archive.

Note: if you need to work with business days, I’ve been recently made aware of ObjectLab Kit. I haven’t used it yet, and feedbacks are welcomed.

Categories: Java Tags: