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...