EclipseLink 2.4:

EclipseLink 2.4.0 Juno - RELEASED

As part of the Juno Eclipse release train the EclipseLink project has released EclipseLink 2.4.0. The release landing page describes some of the new and noteworthy features as well as providing links to documentation and examples so you can get started. What I would like to do is provide some colour commentary on the features new in this release.

JSON Binding

EclipseLink’s MOXy component has offered a JAXB compliant implementation for many years now.  It not only supports the standard JAXB features but also goes well beyond the standard to offer powerful advanced features, including XPath mappings, and support for defining mappings in XML instead of just annotations. 

In EclipseLink 2.4.0, MOXy has expanded its scope to support mapping Java objects to JSON. This support covers all of the MOXy mappings available in annotations, XML, and now JSON.  MOXy’s JSON support is enabled simply by setting the desired media-type on a marshaller or unmarshaller.  This support is unique as it marshalls/unmarshalls objects directly to and from JSON without any intermediate conversions.  And EclipseLink MOXy’s integration with EclipseLink JPA, originally written for XML mapping, makes serializing JPA entities to and from JSON easy.

Learn more about EclipseLink MOXy's JSON ...

HTML5/Mobile

During the development of 2.4 the team introduced JSON binding and we started building sample applications illustrating how this functionality could be leveraged with JAX-RS to simplify development. This lead us to discussions with the Jersey team as to how EclipseLink could better integrated. I parallel we continue to look at different client technologies to see what we can do in the persistence layer to simplify development. The convergence of these efforts is EclipseLink's JPA-RS feature which provides RESTful access to persistence units with either XML or JSON data formats.

What I find most interesting about JPA-RS is what it offers to developers looking to access data for Thin Server Architecture (TSA) clients. In many cases client developers just need data in a consumable (and of course efficient and secure) format and having to build a full Java EE application to expose this data can be a barrier to entry. What we have done with JPA-RS is simplified how new applications can be developed with a JAX-RS+JPA back-end with minimal server side development.

Learn more about JPA-RS...

Cloud Enabled Persistence

Starting in EclipseLink 2.3 the EclipseLink team started exposing features to simplify development of applications that will be deployed in a cloud infrastructure or need to work in PaaS or SaaS scenarios. The solutions introduced included:

• @Multitenant(SINGLE_TABLE) allowing tables to store data from multiple tenants leveraging row level filtering.
• Extensible entities using virtual attributes so that the entity types can be customized post deployment to manage additional state.
• MetadataSource allows overriding mapping metadata (JPA and MOXy) to be retrieved dynamically during deployment or on refresh request. This allows persistence unit customization post development so that applications can be customizable at runtime as well as supporting deployment architectures where tenant specific extensions are enabled.

In EclipseLink 2.4 we have further extended this support to include some additional tenant isolation options.

• @Multitenant(TABLE_PER_TENANT) allows different tables in the same schema to be used per tenant or dedicated schemas per tenant.
• MetadataSource has been extended to allow persistence unit properties, including data source information, to be dynamically provided at startup and refresh. This allows PaaS deployed application instances to retrieve isolated data source information per tenant.

Learn more about EclipseLink's Tenant Isolation features ...

NoSQL

EclipseLink, even before it was open sourced at Eclipse, offered developers support for mapping their persistent entities to non-relational data sources.  This support was done using the little known EIS features where JCA resource adapters were used and mappings were made to XML or record structures.  This core support in the foundation component has been reborn in the EclipseLink NoSQL component. This first release of EclipseLink NoSQL that ships in conjunction with our primary 2.4.0 release provides mapping and querying capabilities with MongoDB and Oracle NoSQL.

Although Object-Relational persistence for NoSQL may not apply in all scenarios it does appeal to developers who wish to use Objects and find the existing Java Persistence interfaces more natural to integrate with versus a unique data-centric API provided by the NoSQL vendors.

This area of EclipseLink persistence will be challenging given the lack of standards and wide variety of NoSQL stores available and we are hoping this first release will allow us to gain experience with how developers want to access NoSQL from their Java applications. We'll learn both where a solution like this fits well as well as where it is best not used. We will be looking to the community for feedback on the support offered, new features wanted, as well as what additional NoSQL databases we should consider supporting in future releases of EclipseLink NoSQL.

Learn more about EclipseLink NoSQL ...

And Much More...

 We continue to evolve what a Java Persistence solution can do and have many plans for new features. The primary source of our requirements is based on our users. If you are using EclipseLink and like what you see then please let the developers know. If you don't like something we also want to hear about that. If you have never tried EclipseLink then what are you waiting for. Download the new EclipseLink 2.4 release and let us know what you think.

Feedback

• EclipseLink Newsgroup
• Twitter: #EclipseLink or @EclipseLink
• EclipseLink Bugzilla

Czech Republic visit and EclipseLink Indigo (2.3)

Last week when I was in Prague I had the oppurtunity to catch up with Alexis-Moussine Pouchkine (@alexismp). While there Alexis recorded an interview with me about EclipseLink and we both spoke at the Java Developer Conference in Brno.

• Alexis Summary of developer conference
• GlassFish PodCast on EclipseLink

The developer conference was my first opportunity to present a talk on the work we have been doing within the EclipseLink project to address development of applications for the cloud. More specifically we have been busy working on some features which I think will be very interesting to all Java EE developers using JPA. These include:

• @Multitenant: Support for configuring entities which have data from different tenants stored in the same table. EclipseLink will automatically apply additional criteria on all queries to only read and modify the rows for your current tenant.
• Extensible Entities with Virtual Attributes (@VirtualAccessMethods): Allow for attributes to be mapped to database flex columns on the fly. This includes both JPA and JAXB mappings/bindings as well as tenant specific extensions.
• MetadataSource: Allow for your XML specified JPA mappings or JAXB bindings to be dynamically loaded and used by your application from an external source. This allows you to customize your application on-the-fly from an external source.

In my presentation I did a demo of my new MySports demo application which I am busy wrapping up and documenting for the Eclipse Indigo release (June 22). This application shows off the new features with a multitenant JSF application which includes dynamic JSF rendering of extended attributes using the JPA 2.0 metamodel. The tenant configuration and provisioning is done using an admin application which uses REST and EclipseLink MOXy's binding support.

It should be a busy month wrapping up all of the necessary documentation and examples for the Indigo release so that EclipseLink

Oracle @ EclipseCon

Although it does not look like I will make it to Santa Clara this year for EclipseCon the rest of the team here at Oracle has put together an impressive set of sessions. If you are planning on attending EclipseCon here is a summary of the Oracle related sessions.

http://wikis.sun.com/display/EC2011/Oracle+at+EclipseCon+2011

JPA 2.0 in WebLogic with OEPE

To add to my previous post. Greg Stachnick has posted the steps for enabling JPA through the Oracle Enterprise Pack for Eclipse.

Doug

Using JPA 2.0 in WebLogic 10.3.4

Starting with the Oracle WebLogic 10.3.4 release it is now possible to upgrade to using JPA 2.0. The release includes TopLink 11.1.1.4 (with EclipseLink 2.1.2).

Since WebLogic 10.3.4 is a compliant Java EE 5 implementation it is required to ship out of the box with support for EJB 3.0 and thus JPA 1.0. If you wish to upgrade your install to allow JPA 2.0 use you must follow install a small patch, which is documented here.

If you are making use of Oracle Enterprise Pack for Eclipse the new 11.1.1.6.1 includes support for using the JPA 2.0 capabilities.

Doug

EclipseLink Filters How-To

I have been assisting customers with their comparison of JPA/Object-relational frameworks as well as assisting them with migrating to EclipseLink JPA. One issue I ran into recently involves migrating users of Hibernate who use Filters over to EclipseLink. A filter is basically an additional set of criteria with session specific arguments that are applied to all queries of a given entity type.

EclipseLink has long supported additional criteria being configured on a descriptor (mapping for an entity type). In this blog I just wanted to post some simple example code that illustrates how additional criteria can be applied to a an entity type with parameters that are then specified in the creation of the EntityManager where the criteria is to be applied.

Using either an annotation on the entity class as:

@Entity
@Customizer(AddEmployeeGenderCriteria.class)
public class Employee

Alternatively this customizer can be configured in persistence unit properties as well as in the eclipselink-orm.xml mapping file.

This allows for a provided customer to be called and the descriptor for the entity type, Employee in this case, to be customized. Here we'll add the additional criteria (filter) that will later be used.

public static class AddEmployeeGenderCriteria implements DescriptorCustomizer {

public void customize(ClassDescriptor descriptor) throws Exception {
ExpressionBuilder eb = new
ExpressionBuilder(descriptor.getJavaClass());
Expression genderExp = eb.get("gender").equal(new
SessionPropertyValue("gender"));
descriptor.getQueryManager().setAdditionalJoinExpression(genderExp);
}

}

Note: The SessionPropertyValue class is an extension and is only required if the criteria has a parameter value that will be supplied dynamically per EntityManager.

Now with the descriptor has been customized with the additional criteria for all Employee queries we simply need to provide the argument value when creating the EntityManager.

properties.put("gender", "M");
EntityManager em = emf.createEntityManager(properties);

This will cause all queries such as:

em.createQuery("SELECT e FROM Employee e WHERE e.firstName LIKE 'J%'", Employee.class).getResultList();

To have the addtitional criteria added and the SQL generated appears as:

SELECT t0.EMP_ID, t1.EMP_ID, t0.L_NAME, t0.END_TIME, t0.VERSION, t0.START_TIME, t0.GENDER, t1.SALARY, t0.F_NAME, t0.MANAGER_ID, t0.ADDR_ID, t0.START_DATE, t0.END_DATE FROM EMPLOYEE t0, SALARY t1 WHERE (t0.F_NAME LIKE ? AND ((t1.EMP_ID = t0.EMP_ID) AND (t0.GENDER = ?)))
bind => [J%, M]

The only additional requirement is that the entity types with the EntityManager specific 'filters' be only cached in the EntityManager (isolated/txn cache) instead of the default shared cache to ensure that filtered collections from one context are not incorrectly presented in another where different parameter values are used.

The use of these types of filters is not all that common in my experience so improving the configuration has not been a priority. If you use these filters and would like to have the usage of them in EclipseLink improved we are eager to get your feedback.

Off to Epicenter in Dublin

I am once again off to Dublin this week to speak at the Epicenter 2010 Conference again. Although I do enjoy a good Guiness I am also looking forward to the conference and the topics I am covering this week as well as the hours of travel to catch up on some pre-release tasks. We are just wrapping up our 2.1 release of EclipseLink as part of the Eclipse Helios release train and there are many new features I am excited about so travelling this week will give me a chance to complete some examples for the release and blog about the features all EclipseLink users will want to learn about.

I am speaking this week on performance and scalability. Even after 13 years of helping customers use TopLink and now EclipseLink I still find diagnosing, solving, and innovating in these areas some of the most interesting work I take part in. Helping customers learn what they need to know about their models and application use cases and translating them into their object-relational mappings, schema, and usage of their persistence layer is challenging and often poorly understand by Java developers.

The persistence layer enables performance and scalability but there are many simple decisions developers can make while configuring and coding to their persistence layer which are made early in projects and have big effects late in projects when trying to reach their performance and scalability goals. Understanding what these decisions are and what the trade-offs are is so important and hopefully I'll help some of our Irish community avoid common pitfalls.

After working with a couple clients this week dealing with tough performance goals and very complex models I have some great examples I'll be adding to my cook book of slides on my way over the Atlantic.

Hope to see you in Dublin...

EclipseLink on LinkedIn

I was back in the field last week helping a customer with their migration to EclipseLink from a 3rd party developed solution using TopLink Essentials. Generally these migrations are very straight forward but in this case we bumped into a few unique wrinkles caused by the original solution being developed on a very early version of our JPA 1.0 solution and the consultants building it introducing a partial JPA container that changed the default behaviour.

Ultimately we got the issues resolved in relatively short order and enjoyed a great meal with some of the consultants on the project in Halifax. I truly enjoy any chance I get to down into an application and help developers solve their persistence challenges.

During my visit I made some notes on a couple of take-aways.

1. Update the EclipseLink wiki's best practices to include a couple of additional scenarios around long-running transactions.

2. Help connect the existing community of Java professionals using EclipseLink.

I have already started on the first and will post some highlights here when the work is completed. To address the second action item I created the EclipseLink Group on LinkedIn.

The goal of this group is to allow any and all Java professionals who use LinkedIn to connect and share ideas, job opportunities, news, and upcoming events. If this sounds interesting to you please join the group and share your ideas.

Doug

Oracle Enterprise Pack for Eclipse 11g released at EclipseCon 2009

Enjoying another fun and informative week at EclipseCon.

The OEPE 11g release announced today includes excellent ORM tooling based on Dali as well as specific support for EclipseLink. Check out Pieter Humphrey's Blog entry for all the details.

Doug

My Thoughts on EclipseLink 1.0

We released EclipseLink 1.0. You can read about it on the EclipseLink Team Blog. Please do download it and try it out.

Its been an interesting year since we first announced the contribution of Oracle TopLink to open source and the creation of the EclipseLink project. Taking a large product and all of its testing and moving it to a new repository with new build and test servers was technically challenging. Probably the more interesting changes however have been in how we developed 1.0 and the future releases of the project. Learning the Eclipse 'way' (project reviews, code contributions and the IP process, detailed road maps and public updates, web site, portal, wiki, bugzilla, ...) has been fun and interesting while only occasionally painful. Transitioning a large development team to this new open process was well worth the effort. We are now a community of committers that expands beyond just Oracle.

This 1.0 release is really based on several years of development. This past year within the EclipseLink project plus all of the functionality developed in Oracle TopLink since our 10.1.3 release (February 2006) is included. While we tend to focus on the efforts of the past year many Oracle TopLink customers will find a significant amount of new features in the classic ORM/OXM support in addition to all the great new JPA/JAXB/SDO support. Over the next few weeks I will try to post blogs highlighting many of these features and how they can be used.

There are a few high level items about this release I would like to point out:

Minimal Dependencies: We ship with an eclipselink.jar library for JavaSE/EE users that can be used easily with minimal additional libraries. JPA users in JavaSE will just need to include the JPA 1.0 library (included as /jlib/jpa/persistence_1.0.0.jar) and their favourite JDBC driver. Within a JavaEE5 container you will just need the EclipseLink library as JPA should already be available as well as your JDBC drivers within the container's Data Source. Minimal dependencies is very important as it simplifies usage and avoids conflicts with other frameworks and your container's use of common libraries.

Full Functionality: No matter how many times I say this I still get questions after my talks and webinars. All of the persistence functionality of Oracle TopLink is included in EclipseLink. All of the TopLink development team now exclusively develops new functionality in EclipseLink.

We have also done a fair bit of work to enable the usage of our many advanced features through JPA. This includes custom annotations as well as XML configuration. Our goal is to keep developers as close to standard JPA as possible and simplify usage when you do need EclipseLink JPA's advanced features.

OSGi Support: While I still personally feel like a newbie in the OSGi space I am very proud of how our developers have managed to address class-loader flexibility so that we can bundle our EclipseLink components for use in OSGi. The optional Equinox functionality to enable Dynamic/Load-Time weaving allows developers using Equinox (typically RCP) to build full featured JPA applications without fighting the persistence implementation. We have an example available if you want to try it out.

Flexible Object Binding: The MOXy component does support JAXB2's annotations and XML schema compiler but what I think is most interesting is the ability to externalize the XML binding information. EclipseLink MOXy has its own XML mapping file as well as supporting mappings defined in code (statically or dynamically). Using this externalized mapping support with the standard JAXB marshal/unmarshal API is very powerful and allows a domain model to be easily persisted to multiple data sources/formats.

Performance and Scalability: One aspect of Oracle TopLink development is that while we continued to evolve the product over the past 12 years we have always focussed on ensuring we had a well tuned core engine and many tuneable options available so our customers can address their performance and scalability goals. The Oracle TopLink product has been a key contributor to Oracle's world record SpecJ benchmarks and all of the optimizations introduced to address high levels of concurrent processing are now available in EclipseLink. We believe we have the fastest persistence solution available and will work hard to continue proving that through public benchmarking activities.

I would like to thank everyone involved in making the EclipseLink 1.0 release happen. From the developers/QA/writers/managers who helped produce it (and put up with me) to the Oracle management who supported us through this process and all of our user community for the feedback and encouragement.

Cheers,

Doug

Graduation

Its been a big week for graduations. Earlier this week my son completed his time in kindergarden and today the EclipseLink project graduated from incubation status. Tonight I took a few minutes to finally remove the big egg from the EclipseLink home page.

As for my son, he is pretty focussed on spending every waking hour swimming until September. As for EclipseLink we are about ready to ship our 1.0 release on July 9th. In both cases it should be a fun and exciting summer.

We have been getting great feedback so far on EclipseLink and I would like to invite the entire Java community to download EclipseLink and try it out. We are eager to get your feedback and continue to expand the usage of our project.

Doug

EclipseLink in the News

Pretty exciting day so far at EclipseCon. We have been involved in two press releases at the conference so far.

Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation

• Read more on the EclipseLink Team BLOG

Eclipse Announces New Runtime Initiative around Equinox

Ian Skerrett discusses this announcement and its implications. This announcement has a couple effects to the EclipseLink project. First off it provides a new top level project for us. We will move from the Technology project to the newly created Runtime project in the near future. This also formalizes our relationship with Equinox. We will soon be checking in our work to enabled EclipseLink's effective use in an OSGi environment.

Now that we have these announcements out I am looking forward to spending more time talking to other attendees about their work and how EclipseLink may be of use in their projects and applications.

Doug

Testing EclipseLink JPA applications in JavaSE

I spend part of my work days writing examples and helping users debug issues. I spend the majority of this time using JPA with our TopLink and now EclipseLink's advanced features.

One little piece of code I always find myself looking for is a way to take a JPA persistence unit configuration and use it in JavaSE without changing it. The idea is that my persistence unit which should run in the container should also be testable easily outside.

In the past I posted some examples of using XML to accomplish this but the following is the Java code that I use in my JavaSE examples and unit tests without going down the road of a separate persistence unit definition in XML for both worlds.

import static org.eclipse.persistence.jpa.config.PersistenceUnitProperties.*;

...

Map properties = new HashMap();

// Ensure RESOURCE_LOCAL transactions is used.
properties.put(TRANSACTION_TYPE,
  PersistenceUnitTransactionType.RESOURCE_LOCAL.name());

// Configure the internal EclipseLink connection pool
properties.put(JDBC_DRIVER, "oracle.jdbc.OracleDriver");
properties.put(JDBC_URL, "jdbc:oracle:thin:@localhost:1521:ORCL");
properties.put(JDBC_USER, "user-name");
properties.put(JDBC_PASSWORD, "password");
properties.put(JDBC_READ_CONNECTIONS_MIN, "1");
properties.put(JDBC_WRITE_CONNECTIONS_MIN, "1");

// Configure logging. FINE ensures all SQL is shown
properties.put(LOGGING_LEVEL, "FINE");

// Ensure that no server-platform is configured
properties.put(TARGET_SERVER, TargetServer.None);

I can then create my EntityManagerFactory using:

Persistence.createEntityManagerFactory("unit-name", properties);

The only remaining struggle I have is specifying which classes are my entities. The simplest way is to explicitly reference them in the persistence.xml or an associated orm.xml file. If they are listed explicitly then I do not need to worry about the automatic discovery.

EclipseLink does support automatic discovery of entity classes in JavaSE but you need to enable its usage using:

<persistence-unit name="unit-name">
<exclude-unlisted-classes>false</exclude-unlisted-classes>
</persistence-unit>

Hopefully having these snippets of code and XML handy will help some of you out and now I can easily find them wherever I am working.

Doug

Java Search Engine Integration for EclipseLink JPA

The creator and primary contributor to Compass has taken the initiative to provide support for using EclipseLink (www.eclipselink.org) with Compass. I hope to find the time to build an application that illustrates the use of the two projects but thought I would post some early information to the community about the integration.

See the documentation


Compass is described as:

Compass is a first class open source Java Search Engine Framework, enabling the power of Search Engine semantics to your application stack decoratively. Built on top of the amazing Lucene Search Engine, Compass integrates seamlessly to popular development frameworks like Hibernate, [and now EclipseLink] and Spring. It provides search capability to your application data model and synchronizes changes with the datasource. With Compass: write less code, find data quicker.

For those of you interested in adding richer search capabilities to your JPA applications you can now combine the capabilities of Lucenewith EclipseLink JPA through the Compass integration.

Cheers,

Doug

EclipseLink 1.0 Milestone 1: Now Available

We just made our first milestone build available for download. See the EclipseLink team blog for more information.

This is an important step for our project. Our plan is to produce monthly milestone builds as we work toward our 1.0 release. It does seem very odd to be starting back at a 1.0 release after over 10 years of shipping this Java persistence solution. For those familiar with TopLink this milestone is the complete capabilities from the Oracle TopLink 11gR1 Technology Preview 2. Since we were near completion of our development cycle for this release the new features available are complete and well tested.

We are also in the process of publishing the complete documentation from Oracle TopLink as the EclipseLink user manuals. This will be done on the wiki. This in conjunction with the evolving set of examples should help developers easily evaluate the use of this project.

Any and all feedback is appreciated. There is a newsgroup and users mailing list where feedback can be provided.

All information on the EclipseLink project can be found linked from our home page.

Cheers,

Doug

EclipseLink Update: Source Checked in and team Blog

See the EclipseLink team blog for regular updates on the project.

Doug

Its alive...

I am just heading out on vacation this morning and wanted to update the community on our progress in the Eclipse new project process. We have completed our initial incubation provisioning of the Eclipse Persistence Services Project (EclipseLink).

We now have our home page up (www.eclipse.org/eclipselink) with a wiki home and developer mailing list.

We are initiating the Eclipse Parallel IP review process to get the TopLink source and test case contribution into the subversion repository in the near future. This process of re-packaging and organizing the source has been very interesting.

In the coming weeks we'll get the source code in and builds and testing working. We'll publish our roadmap and focus on building new features and a strong community. Stay tuned....

Doug

Eclipse Persistence Services Project - Passed Creation Review

We are now busy working through the logistics of provisioning the product and getting the initial code contribution available through the parallel IP process.

If you have any questions please post them to the forum.

Cheers,

Doug

Simple Auditing using TopLink JPA

In a forum post on the Oracle TopLink forum on OTN there was a request for an approach to tracking entity history in a separate table. While Oracle TopLink includes support for automatic historical versioning this support does not exist in TopLink Essentials.

The following is a simple example for how you might do historical versioning of your persistent entities using TopLink Essentials and JPA. There are many approaches to how you would design your schema for managing this additional state. I kept my approach simple where the primary data table uses an integer version optimistic locking column and the history table stores a row for each version of the primary table.

The sample model is simply an Employee entity and its history is stored in an EmployeeHistory entity.

@Entity
@NamedQuery(name = "Employee.findAll",
query = "select e from Employee e ORDER BY e.lastName ASC, e.firstName ASC")
@TableGenerator(name = "emp-seq-table", table = "SEQUENCE",
pkColumnName = "SEQ_NAME", valueColumnName = "SEQ_COUNT",
pkColumnValue = "EMP_SEQ", allocationSize = 26)
public class Employee {
@Id
@GeneratedValue(strategy = GenerationType.TABLE,
generator = "emp-seq-table")
@Column(name = "EMP_ID", nullable = false)
private int id;

@Column(name = "F_NAME")
private String firstName;

@Column(name = "L_NAME")
private String lastName;

private String gender;

@Version
private long version;

...

@Entity
@IdClass(EmployeeHistory.ID.class)
@Table(name = "EMPLOYEE_HISTORY")
@NamedQuery(name="EmployeeHistory.findAllForEmployee", query="SELECT eh FROM EmployeeHistory eh WHERE eh.employee = :EMP")
public class EmployeeHistory {
@Id
@Column(name = "EMP_ID")
private int id;

@Id
private long version;

@ManyToOne
@JoinColumn(name = "EMP_ID", referencedColumnName = "EMP_ID", insertable=false, updatable=false)
private Employee employee;

@Column(name = "F_NAME")
private String firstName;

@Column(name = "L_NAME")
private String lastName;

private String gender;

/**
*
* @param emp
*/
protected EmployeeHistory(Employee emp) {
this.id = emp.getId();
this.version = emp.getVersion();
this.firstName = emp.getFirstName();
this.lastName = emp.getLastName();
this.gender = emp.getGender();

this.employee = emp;
}

...

Now to have the creation and modification of all Employee instances cause the creation of an EmployeeHistory instance I will use a TopLink Essentials specific event listener.

The descriptor event listener used looks like:

/**
* This is an example of how a TopLink Essentials DescriptorEventListener can be
* used to populate an audit record whenever an update occurs. This class must be
* registered as a persistence unit property in the creation of the
* EntityManagerFactory.
*
* property name="toplink.descriptor.customizer.Employee" value="model.jpa.auditing.EmployeeAuditingHandler"
*
* @since TopLink Essentials v2-Build-41
*/
public class EmployeeAuditingHandler extends DescriptorEventAdapter implements DescriptorCustomizer {

/**
* This is where the real work of this class happens. For any INSERT or UPDATE
* operation an INSERT of a new history object is forced.
*/
private void insertEmployeeHistory(DescriptorEvent event) {
EmployeeHistory empHist = new EmployeeHistory((Employee)event.getSource());
InsertObjectQuery insertQuery = new InsertObjectQuery(empHist);
event.getSession().executeQuery(insertQuery);
}

public void aboutToUpdate(DescriptorEvent event) {
insertEmployeeHistory(event);
}

public void aboutToInsert(DescriptorEvent event) {
insertEmployeeHistory(event);
}

/**
* This method is invoked through this class's registration as a descriptor
* customizer. All it does is register this same object as an event listener
*/
public void customize(ClassDescriptor descriptor) {
descriptor.getEventManager().addListener(this);
}
}

Now with this event listener in place I can proceed in my application using standard JPA coding. Every time I create or modify an Employee entity I will see the associated EmployeeHistory INSERT during the transaction commit.

I hope you find this helpful.

Doug

TopLink Essentials using Oracle Spatial ... a sample application

Andrejus Baranovskis has posted a sample application using Oracle Spatial with TopLink Essentials JPA. The steps are based upon my previous post.

andrejusb.blogspot.com

Doug