deltaspike/modules/data/README.adoc

= DeltaSpike Data
Thomas Hug <thug@apache.org>

///////////
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
.
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
///////////

== DeltaSpike Data

=== Introduction

The repository pattern used to be one of the core J2EE patterns and could be found in 
most enterprise applications reading and writing data to persistent stores. 
While the Java Persistence API (JPA) as part of Java EE 5+ has replaced many aspects of the
repository pattern, it is still a good approach to centralize complex query logic related to 
specific entities.

The DeltaSpike Data module is intended to help you simplifying your repository layer.
While you will have complex queries in a repository requiring your full attention,
there will also be many simple ones often requiring boilerplate code and clutter.
This is where the DeltaSpike data module will help you keeping your repository lean so you 
can focus on the though things.

The code sample below will give you a quick overview on the common usage scenarios of the data module:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> findByAgeBetweenAndGender(int minAge, int maxAge, Gender gender);

    @Query("select p from Person p where p.ssn = ?1")
    Person findBySSN(String ssn);

    @Query(named=Person.BY_FULL_NAME)
    Person findByFullName(String firstName, String lastName);

}
----

As you see in the sample, there are several usage scenarios outlined here:

* Declare a method which executes a query by simply translating its name and parameters into a query.
* Declare a method which automatically executes a given JPQL query string with parameters.
* Declare a method which automatically executes a named query with parameters. 

The implementation of the method is done automatically by the CDI extension. 
A client can declare a dependency to the interface only. The details on how to use those 
features are outlines in the following chapters.

=== Installation

==== Prerequisites

The simplest way using the DeltaSpike data module is to run your application in a Java EE container
supporting at least the Java EE 6 Web Profile. Other configurations like running it inside Tomcat or 
even a Java SE application should be possible - you need to include a JPA provider as well as a CDI container
to your application manually.

Also note that in order to use abstract classes as repositories, this currently requires the presence
of the http://www.javassist.org[javassist] library in your classpath.

==== Maven Dependency Configuration

If you are using Maven as your build tool, you can add the following dependencies to your +pom.xml+
file to include the DeltaSpike data module:

[source,xml]
----
<dependency>
    <groupId>org.apache.deltaspike.modules</groupId>
    <artifactId>deltaspike-data-module-api</artifactId>
    <version>${deltaspike.version}</version>
    <scope>compile</scope>
</dependency>
<dependency>
    <groupId>org.apache.deltaspike.modules</groupId>
    <artifactId>deltaspike-data-module-impl</artifactId>
    <version>${deltaspike.version}</version>
    <scope>runtime</scope>
</dependency>
----

[TIP]
===============================
Substitute the expression +${deltaspike.version}+ with the most recent or appropriate version
of DeltaSpike. Alternatively, you can create a Maven user-defined property to satisfy this 
substitution so you can centrally manage the version. 
===============================

Including the API at compile time and only include the implementation at runtime protects you from
inadvertantly depending on an implementation class.

==== Setup your application

DeltaSpike data requires an +EntityManager+ exposed via a CDI producer - which is common practice
in Java EE 6 applications.

[source,java]
----
public class DataSourceProducer
{

    @PersistenceUnit
    private EntityManagerFactory emf;

    @Produces
    public EntityManager create()
    {
        return emf.createEntityManager();
    }

    public void close(@Disposes EntityManager em)
    {
        if (em.isOpen())
        {
            em.close();
        }
    }

}
----

This allows the +EntityManager+ to be injected over CDI instead of only being used with a
+@PersistenceContext+ annotation. Using multiple +EntityManager+ is explored in more detail
in a following section.

You're now ready to use repositories in your application!

=== Core Concepts

==== Repositories

With the DeltaSpike data module, it is possible to make a repository out of basically any
abstract class or interface (using a concrete class will work too, but you won't be able to use
most of the CDI extension features). All that is required is to mark the type as such with a
simple annotation:

[source,java]
----
@Repository(forEntity = Person.class)
public abstract class PersonRepository {
    ...
}

@Repository(forEntity = Person.class)
public interface PersonRepository {
    ...
}    
----

The +@Repository+ annotation tells the extension that this is a repository for the +Person+ entity.
Any method defined on the repository will be processed by the framework. The annotation does not
require to set the entity class (we'll see later why) but if there are just plain classes or
interfaces this is the only way to tell the framework what entity the repository relates to. 
In order to simplify this, DeltaSpike data provides several base types.

===== The +EntityRepository+ interface

Although mainly intended to hold complex query logic, working with both a repository and an +EntityManager+
in the service layer might unnecessarily clutter code. In order to avoid this for the most common cases,
DeltaSpike data provides base types which can be used to replace the entity manager.

The top base type is the +EntityRepository+ interface, providing common methods used with an +EntityManager+.
The following code shows the most important methods of the interface:

[source,java]
----
public interface EntityRepository<E, PK extends Serializable>
{

    E save(E entity);

    void remove(E entity);

    void refresh(E entity);

    void flush();

    E findBy(PK primaryKey);

    List<E> findAll();

    List<E> findBy(E example, SingularAttribute<E, ?>... attributes);

    List<E> findByLike(E example, SingularAttribute<E, ?>... attributes);

    Long count();

    Long count(E example, SingularAttribute<E, ?>... attributes);

    Long countLike(E example, SingularAttribute<E, ?>... attributes);

} 
----

The concrete repository can then extend this basic interface. For our Person repository,
this might look like the following:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    Person findBySsn(String ssn);

} 
----

[TIP]
===============================
Annotations on interfaces do not inherit. If the +EntityRepository+ interface is extended by another
interface adding some more common methods, it is not possible to simply add the annotation there.
It needs to go on each concrete repository. The same is not true if a base class is introduced,
as we see in the next chapter. 
===============================

===== The +AbstractEntityRepository+ class

This class is an implementation of the +EntityRepository+ interface and provides additional functionality
when custom query logic needs also to be implemented in the repository.

[source,java]
----
public abstract class PersonRepository extends AbstractEntityRepository<Person, Long>
{

    public Person findBySSN(String ssn)
    {
        return getEntityManager()
                .createQuery("select p from Person p where p.ssn = ?1", Person.class)
                .setParameter(1, ssn)
                .getResultList();
    }

}
----

==== Using Multiple +EntityManager+

While most applications will run just fine with a single +EntityManager+, there might be setups
where multiple data sources are used. This can be configured with the +EntityManagerConfig+ annotation:

[source,java]
----
@Repository
@EntityManagerConfig(entityManagerResolver = CrmEntityManagerResolver.class, flushMode = FlushModeType.COMMIT)
public interface PersonRepository extends EntityRepository<Person, Long>
{
    ...
}

public class CrmEntityManagerResolver implements EntityManagerResolver
{
    @Inject @CustomerData // Qualifier - assumes a producer is around...
    private EntityManager em;

    @Override
    public EntityManager resolveEntityManager()
    {
        return em;
    }
}
----

Again, note that annotations on interfaces do not inherit, so it's not possible to create something like a base
+CrmRepository+ interface with the +@EntityManagerConfig+ and then extending / implementing this interface.

=== Query Method Expressions

Good naming is a difficult aspects in software engineering. A good method name usually makes 
comments unnecessary and states exactly what the method does. And with method expressions, the 
method name is actually the implementation!

==== Using method expressions

Let's start by looking at a (simplified for readability) example:

[source,java]
----
@Entity
public class Person
{

    @Id @GeneratedValue
    private Long id;
    private String name;
    private Integer age;
    private Gender gender;

}

@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> findByNameLikeAndAgeBetweenAndGender(String name, 
                                  int minAge, int maxAge, Gender gender);

}
----

Looking at the method name, this can easily be read as query all Persons which have a name like
the given name parameter, their age is between a min and a max age and having a specific gender.
The DeltaSpike module can translate method names following a given format and directly generate
the query implementation out of it (in EBNF-like form):

[source]
----
(Entity|List<Entity>) findBy(Property[Comparator]){Operator Property [Comparator]}
----

Or in more concrete words:

* The query method must either return an entity or a list of entities
* It must start with the +findBy+ keyword
* Followed by a property of the Repository entity and an optional comparator (we'll define this later). The property will be used in the query together with the comparator. Note that the number of arguments passed to the method depend on the comparator.
* You can add more blocks of property-comparator which have to be concatenated by a boolean operator. This is either an +And+ or +Or+

Other assumptions taken by the expression evaluator:

* The property name starts lower cased while the property in the expression has an upper cases first character. 

Following comparators are currently supported to be used in method expressions:

[options="header"]
|=======
|Name                |# of Arguments |Description
|Equal               |1              |Property must be equal to argument value. If the operator is omitted in the expression, this is assumed as default.
|NotEqual            |1              |Property must be not equal to argument value.
|Like                |1              |Property must be like the argument value. Use the %-wildcard in the argument.
|GreaterThan         |1              |Property must be greater than argument value.
|GreaterThanEquals   |1              |Property must be greater than or equal to argument value.
|LessThan            |1              |Property must be less than argument value.
|LessThanEquals      |1              |Property must be less than or equal to argument value.
|Between             |2              |Property must be between the two argument values.
|IsNull              |0              |Property must be null.
|IsNotNull           |0              |Property must be non-null.
|=======

Note that DeltaSpike will validate those expressions during startup, so you will notice early in case you have a typo
in those expressions.

==== Query Ordering

Beside comparators it's also possible to sort queries by using the +OrderBy+ keyword, followed
by the attribute name and the direction (+Asc+ or +Desc+).

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> findByLastNameLikeOrderByAgeAscLastNameDesc(String lastName);

} 
----

==== Nested Properties

To create a comparison on a nested property, the traversal parts can be separated by a +_+:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> findByCompany_companyName(String companyName);

}
----

==== Query Options

DeltaSpike supports query options on method expressions. If you want to page a query,
you can change the first result as well as the maximum number of results returned:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> findByNameLike(String name, @FirstResult int start, @MaxResults int pageSize);

}
----

==== Method Prefix

In case the +findBy+ prefix does not comply with your team conventions, this can be adapted:

[source,java]
----
@Repository(methodPrefix = "fetchWith")
public interface PersonRepository extends EntityRepository<Person, Long>
{

    List<Person> fetchWithNameLike(String name, @FirstResult int start, @MaxResults int pageSize);

}
----

=== Query Annotations

While method expressions are fine for simple queries, they will often reach their limit once things
get slightly more complex. Another aspect is the way you want to use JPA: The recommended approach 
using JPA for best performance is over named queries. To help incorporate those use cases, the 
DeltaSpike data module supports also annotating methods for more control on the generated query.

==== Using Query Annotations

The simples way to define a specific query is by annotating a method and providing the JPQL query
string which has to be executed. In code, this looks like the following sample:

[source,java]
----
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query("select count(p) from Person p where p.age > ?1")
    Long countAllOlderThan(int minAge);

}
---- 

The parameter binding in the query corresponds to the argument index in the method.

You can also refer to a named query which is constructed and executed automatically. The +@Query+
annotation has a named attribute which corresponds to the query name:

[source,java]
----
@Entity
@NamedQueries({
    @NamedQuery(name = Person.BY_MIN_AGE,
                query = "select count(p) from Person p where p.age > ?1 order by p.age asc")
})
public class Person
{

    public static final String BY_MIN_AGE = "person.byMinAge";
    ...

}

@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query(named = Person.BY_MIN_AGE)
    Long countAllOlderThan(int minAge);

}
----

Same as before, the parameter binding corresponds to the argument index in the method. If the named
query requires named parameters to be used, this can be done by annotating the arguments with the 
+@QueryParam+ annotation.

[TIP]
===============================
Java does not preserve method parameter names (yet), that's why the annotation is needed.
===============================

[source,java]
----
@NamedQuery(name = Person.BY_MIN_AGE,
            query = "select count(p) from Person p where p.age > :minAge order by p.age asc")
            
...

@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query(named = Person.BY_MIN_AGE)
    Long countAllOlderThan(@QueryParam("minAge") int minAge);

}
----

It is also possible to set a native SQL query in the annotation. The +@Query+ annotation has a native attribute
which flags that the query is not JPQL but plain SQL:

[source,java]
----
@Entity
@Table(name = "PERSON_TABLE")
public class Person
{
    ...
}

@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query(value = "SELECT * FROM PERSON_TABLE p WHERE p.AGE > ?1", isNative = true)
    List<Person> findAllOlderThan(int minAge);

}
----

==== Annotation Options

Beside providing a query string or reference, the +@Query+ annotation provides also two more attributes:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query(named = Person.BY_MIN_AGE, max = 10, lock = LockModeType.PESSIMISTIC_WRITE)
    List<Person> findAllForUpdate(int minAge);

}
----

[options="header"]
|=======
|Name  |Description
|max   |Limits the number of results.
|lock  |Use a specific LockModeType to execute the query.
|=======

Note that these options can also be applied to method expressions.

==== Query Options

All the query options you have seen so far are more or less static. But sometimes you might want
to apply certain query options dynamically. For example, sorting criteria could come from a user
selection so they cannot be known beforehand. DeltaSpike allows you to apply query options at runtime by
using the +QueryResult+ result type:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Query("select p from Person p where p.age between ?1 and ?2")
    QueryResult<Person> findAllByAge(int minAge, int maxAge);

}
----

Once you have obtained a +QueryResult+, you can apply further options to the query:

[source,java]
----
List<Person> result = personRepository.findAllByAge(18, 65)
    .sortAsc(Person_.lastName)
    .sortDesc(Person_.age)
    .lockMode(LockModeType.WRITE)
    .hint("org.hibernate.timeout", Integer.valueOf(10))
    .getResultList(); 
----

CAUTION: Note that sorting is only applicable to method expressions or non-named queries. For named queries it might be possible, but is currently only supported for Hibernate, EclipseLink and OpenJPA.

Note that the +QueryResult+ return type can also be used with method expressions.

==== Pagination

We introduced the +QueryResult+ type in the last chapter, which can also be used for pagination:

[source,java]
----
// Query API style
QueryResult<Person> paged = personRepository.findByAge(age)
    .maxResults(10)
    .firstResult(50);

// or paging style
QueryResult<Person> paged = personRepository.findByAge(age)
    .withPageSize(10) // equivalent to maxResults
    .toPage(5);

int totalPages = paged.countPages();
----

==== Bulk Operations

While reading entities and updating them one by one might be fine for many use cases, applying bulk
updates or deletes is also a common usage scenario for repositories. DeltaSpike supports this with a special
marking annotation +@Modifying+:

[source,java]
----
@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{

    @Modifying
    @Query("update Person as p set p.classifier = ?1 where p.classifier = ?2")
    int updateClassifier(Classifier current, Classifier next);

}
----

Bulk operation query methods can either return void or int, which counts the number of entities affected
by the bulk operation. 

=== Extensions

==== Query Delegates

While repositories defines several base interfaces, there might still be the odd convenience
method that is missing. This is actually intentional - things should not get overloaded for each and
every use case. That's why in DeltaSpike you can define your own reusable methods.

For example, you might want to use the QueryDsl library in your repositories:

[source,java]
----
import com.mysema.query.jpa.impl.JPAQuery;

public interface QueryDslSupport
{
    JPAQuery jpaQuery();
}

@Repository(forEntity = Person.class)
public interface PersonRepository extends QueryDslSupport
{
   ...
}
----   

==== Implementing the Query Delegate

The first step is to define an interface which contains the extra methods for your repositories
(as shown above):

[source,java]
----
public interface QueryDslSupport
{
    JPAQuery jpaQuery();
}
----

As a next step, you need to provide an implementation for this interface once. It's also important
that this implementation implements the +DelegateQueryHandler+ interface (don't worry, this is just
an empty marker interface):

[source,java]
----
public class QueryDslRepositoryExtension<E> implements QueryDslSupport, DelegateQueryHandler
{

    @Inject
    private QueryInvocationContext context;


    @Override
    public JPAQuery jpaQuery()
    {
        return new JPAQuery(context.getEntityManager());
    }

}
----        

As you see in the sample, you can inject a +QueryInvocationContext+ which contains utility methods
like accessing the current +EntityManager+ and entity class.       

Note that, if you define multiple extensions with equivalent method signatures, there is no specific
order in which the implementation is selected.

=== JPA Criteria API Support

Beside automatic query generation, the DeltaSpike data module also provides a DSL-like API to create JPA 2 Criteria queries.
It takes advantage of the JPA 2 meta model, which helps creating type safe queries.

TIP: The JPA meta model can easily be generated with an annotation processor. Hibernate or EclipseLink provide such a processor, which can be integrated into your compile and build cycle.

Note that this criteria API is not intended to replace the standard criteria API - it's rather a utility
API that should make life easier on the most common cases for a custom query. The JPA criteria API's 
strongest point is certainly its type safety - which comes at the cost of readability. We're trying to 
provide a middle way here. A less powerful API, but still type safe and readable.

==== API Usage

The API is centered around the Criteria class and is targeted to provide a fluent interface
to write criteria queries:

[source,java]
----
@Repository(forEntity = Person.class)
public abstract class PersonRepository implements CriteriaSupport<Person>
{

    public List<Person> findAdultFamilyMembers(String name, Integer minAge)
    {
        return criteria()
                .like(Person_.name, "%" + name + "%")
                .gtOrEq(Person_.age, minAge)
                .eq(Person_.validated, Boolean.TRUE)
                .orderDesc(Person_.age)
                .getResultList();
    }

}
----

Following comparators are supported by the API:

[options="header"]
|=======================
|Name                    |Description
|.eq(..., ...)           |Property value must be equal to the given value   
|.in(..., ..., ..., ...) |Property value must be in one of the given values.
|.notEq(..., ...)        |Negates equality
|.like(..., ...)         |A SQL +like+ equivalent comparator. Use % on the value.
|.notLike(..., ...)      |Negates the like value
|.lt(..., ...)           |Property value must be less than the given value.
|.ltOrEq(..., ...)       |Property value must be less than or equal to the given value.
|.gt(..., ...)           |Property value must be greater than the given value.
|.gtOrEq(..., ...)       |Property value must be greater than or equal to the given value.
|.between(..., ..., ...) |Property value must be between the two given values.
|.isNull(...)            |Property must be +null+
|.isNotNull(...)         |Property must be non-null
|.isEmpty(...)           |Collection property must be empty
|.isNotEmpty(...)        |Collection property must be non-empty
|=======================

The query result can be modified with the following settings:

[options="header"]
|=======================
|Name            |Description
|.orderAsc(...)  |Sorts the result ascending by the given property. Note that this can be applied to several properties
|.orderDesc(...) |Sorts the result descending by the given property. Note that this can be applied to several properties
|.distinct()     |Sets distinct to true on the query.
|=======================

Once all comparators and query options are applied, the +createQuery()+ method is called. 
This creates a JPA TypedQuery object for the repository entity. If required, further processing can be applied here.

==== Joins

For simple cases, restricting on the repository entity only works out fine, but once the data model
gets more complicated, the query will have to consider relations to other entities. The module's criteria
API therefore supports joins as shown in the sample below:

[source,java]
----
@Repository
public abstract class PersonRepository extends AbstractEntityRepository<Person, Long>
{

    public List<Person> findByCompanyName(String companyName)
    {
        return criteria()
                .join(Person_.company,
                    where(Company.class)
                        .eq(Company_.name, companyName)
                )
                .eq(Person_.validated, Boolean.TRUE)
                .getResultList();
    }

}
----

Beside the inner and outer joins, also fetch joins are supported. Those are slighly simpler as seen in the next sample:

[source,java]
----
public abstract class PersonRepository extends AbstractEntityRepository<Person, Long>
{

    public Person findBySSN(String ssn)
    {
        return criteria()
                .fetch(Person_.familyMembers)
                .eq(Person_.ssn, ssn)
                .distinct()
                .getSingleResult();
    }

}
----

==== Boolean Operators

By default, all query operators are concatenated as an and conjunction to the query. The DeltaSpike
criteria API also allows to add groups of disjunctions.

[source,java]
----
public abstract class PersonRepository extends AbstractEntityRepository<Person, Long>
{

    public List<Person> findAdults()
    {
        return criteria()
                .or(
                    criteria().
                        .gtOrEq(Person_.age, 18)
                        .eq(Person_.origin, Country.SWITZERLAND),
                    criteria().
                        .gtOrEq(Person_.age, 21)
                        .eq(Person_.origin, Country.USA)
                )
                .getResultList();
    }

}
----

==== Selections

It might not always be appropriate to retrieve full entities - you might also be interested
in scalar values or by modified entity attributes. The Criteria interface allows this with the
selection method:

[source,java]
----
public abstract class PersonRepository extends AbstractEntityRepository<Person, Long>
{

    public Statistics ageStatsFor(Segment segment)
    {
        return criteria()
                 .select(Statistics.class, avg(Person_.age), min(Person_.age), max(Person_.age))
                 .eq(Person_.segment, segment)
                 .getSingleResult();
    }

    public List<Object[]> personViewForFamily(String name)
    {
        return criteria()
                 .select(upper(Person_.name), attribute(Person_.age), substring(Person_.firstname, 1))
                 .like(Person_.name, name)
                 .getResultList();
    }

}
----

There are also several functions supported which can be used in the selection clause:

[options="header"]
|=======================
|Name                             |Description
|abs(...)                         |Absolute value. Applicable to Number attributes.
|avg(...)                         |Average value. Applicable to Number attributes.
|count(...)                       |Count function. Applicable to Number attributes.
|max(...)                         |Max value. Applicable to Number attributes.
|min(...)                         |Min value. Applicable to Number attributes.
|modulo(...)                      |Modulo function. Applicable to Integer attributes.
|neg(...)                         |Negative value. Applicable to Number attributes.
|sum(...)                         |Sum function. Applicable to Number attributes.
|lower(...)                       |String to lowercase. Applicable to String attributes.
|substring(int from, ...)         |Substring starting from. Applicable to String attributes.
|substring(int from, int to, ...) |Substring starting from ending to. Applicable to String attributes.
|upper(...)                       |String to uppercase. Applicable to String attributes.
|currDate()                       |The DB sysdate. Returns a Date object.
|currTime()                       |The DB sysdate. Returns a Time object.
|currTStamp()                     |The DB sysdate. Returns a Timestamp object. 
|=======================

=== Auditing

A common requirement for entities is tracking what is being done with them. DeltaSpike provides
a convenient way to support this requirement.

TIP: DeltaSpike does not support creating revisions of entities. If this is a requirement for your audits, have a look at Hibernate Envers.

==== Activating Auditing

DeltaSpike uses an entity listener to update auditing data before entities get created or update.
The entity listener must be activated before it can be used. This can either be done globally for
all entities of a persistent unit or per entity.

Activation per persistence unit in +orm.xml+:

[source,xml]
----
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd" version="2.0">
    <persistence-unit-metadata>
        <persistence-unit-defaults>
            <entity-listeners>
                <entity-listener class="org.apache.deltaspike.data.impl.audit.AuditEntityListener" />
            </entity-listeners>
        </persistence-unit-defaults>
    </persistence-unit-metadata>
</entity-mappings>
----

Activation per entity:

[source,java]
----
@Entity
@EntityListeners(AuditEntityListener.class)
public class AuditedEntity
{

    ...

}
---- 

==== Using Auditing Annotations

All that has to be done now is annotating the entity properties which are used to audit the entity.

===== Updating Timestamps

To keep track on creation and modification times, following annotations can be used:

[source,java]
----
@Entity
public class AuditedEntity
{

    ...

    @Temporal(TemporalType.TIMESTAMP)
    @CreatedOn
    private Date created;

    @Temporal(TemporalType.TIMESTAMP)
    @ModifiedOn
    private Date updated;

    ...

}
----

In case the modification date should also be set during entity creation, the annotation can be customized:

[source,java]
----
@ModifiedOn(setOnCreate=true)
----

===== Who's Changing My Entities?

Beside keeping track of when a change has happened, it's also often critical to track who's responsible
for the change. Annotate a user tracking field with the following annotation:

[source,java]
----
@Entity
public class AuditedEntity
{

    ...

    @ModifiedBy
    private String auditUser;

    ... 

}
----

Now a little help is needed. The entity listener needs to be able to resolve the current user -
there must be a bean available of the matching type for the annotation property, exposed over a special CDI qualifier:

[source,java]
----
public class UserProvider
{

    @Inject
    private User user;

    @Produces @CurrentUser
    public String currentUser() {
        return user.getUsername();
    }

    ... 

}
----        

TIP: The JPA Spec does not recommend to modify entity relations from within a lifecycle callback. If you expose another entity here, make sure that your persistence provider supports this. Also you should ensure that the entity is attached to a persistent context. Also, be aware that the CDI container will proxy a scoped bean, which might confuse the persistence provider when persisting / updating the target entity.