Introducing EclipseLink
EclipseLink JPA and Tooling
One of the most common misconceptions is that all open source projects at the Eclipse Foundation are focussed on the Eclipse IDE. While the Eclipse IDE is what Eclipse may be best known for, it is definitely not the only type of project being developed and maintained at Eclipse. EclipseLink is a runtime persistence solution for Java EE, Java SE, Web, and OSGi environments. While it does offer useful development utilities it is a runtime solution and is not dependent on the Eclipse IDE.
However, developers who do use the Eclipse IDE can take advantage of the JPA tooling support offered by the Dali Java Persistence Tools project. Beyond Eclipse, Oracle JDeveloper and Sun's NetBeansTM will both be offering extended support for EclipseLink's advanced features in upcoming releases.
Within the Eclipse Ganymede release users of the Dali tooling will find both standard JPA support as well as support for EclipseLink specific features. When you use the New JPA Project wizard
you can specify which JPA runtime platform you wish to use.
By selecting EclipseLink you enable rich editors for configuring many of EclipseLink's advanced features including:
- Connection Pooling
- Logging
- Schema Generation
- Weaving ConfigurationC
- Customizers and Event Listeners
EclipseLink and OSGi
OSGi has a growing presence in the Java community. However, one of the challenges to OSGi development is lack of commercial and open source frameworks that are fully OSGi compatible. EclipseLink 1.0 is fully compatible with OSGi. Unlike other persistence frameworks, EclipseLink is packaged as a set of OSGi bundles ready for use on any OSGi runtime. Among those using EclipseLink in OSGi is Sun Microsystems in the GlassFish V3 application server which is based on the Apache Felix OSGi runtime. While running on all OSGi runtimes, EclipseLink is able to leverage runtime specific features. For example, in Equinox, EclipseLink JPA integrates with the advanced class loading infrastructure to enable byte code weaving of Entities.
How to get started with EclipseLink?
Those wanting to use EclipseLink in their projects have a number of options available. The EclipseLink project's home at the Eclipse Foundation (www.eclipse.org/eclipselink ) provides access to official releases, monthly milestones, nightly builds and direct access to the project's Subversion code repository. Also available are developer and user mailing lists, newsgroup, complete documentation hosted on the wiki, and examples illustrating how to use EclipseLink in a variety of situations.
In addition to direct access to EclipseLink from the project's home at Eclipse.org, developers can also find EclipseLink in a number of commercial products and open source projects. EclipseLink will be included with Oracle TopLink so it will be available in future versions of Oracle's Application Server. Sun Microsystems' selection of EclipseLink as the JPA 2.0 reference implementation means that EclipseLink is included with both GlassFish and the Sun Application Server. As of version 2.5.2, the Spring Framework ships EclipseLink and includes the necessary code to allow it to be used as an integrated JPA provider. This initial list is substantial in terms of the number of Java developers who have or will have access to EclipseLink through the other products and open source projects they already use.
For developers currently using Oracle TopLink or TopLink Essentials, EclipseLink is a natural upgrade. EclipseLink is Oracle's strategic Java persistence implementation within Oracle Fusion Middleware going forward. How-to guides focused on migration to EclipseLink from previous versions as well as migration utilities to simplify the slight metadata and package naming changes are provided.
Summary
The EclipseLink project's emergence in the open source Java community is intended to change the landscape in this space. We currently have dedicated group of 28 committers from Oracle and Sun as well as additional contributions from a growing community. Our challenge is to continue what we started with TopLink where we evolved the product based on the changes in Java technology and the feedback of our users. Now we need to grow as an open source community consisting of committers, contributors and users where open communication channels enable feedback and ongoing evolution of the project. We invite you to download EclipseLink for yourself and participate in the growing community around the project.
Authors:
Doug Clarke - douglas.clarke@oracle.com
Director of Product Management - Oracle TopLink
EclipseLink Project co-lead
Eclipse RT Project PMC
Eclipse Architecture Council
Shaun Smith - shaun.smith@oracle.com
Principal Product Manager - Oracle TopLink
EclipseLink Eco-System Development Lead
Eclipse Dali and Teneo Projects Committer
- « first
- ‹ previous
- 1
- 2
- 3
- 4
- Login or register to post comments
- 63210 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Vijay Nair replied on Tue, 2008/07/01 - 12:10pm
HI, Does this support out-of the box integration with Coherence as the second level cache or even ehCache ?
Didnt see any property setting for that anywhere in the examples
Tks..VJ
Doug Clarke replied on Tue, 2008/07/01 - 3:10pm
VJ,
EclipseLink 1.0 has added cache interceptors to enable us to leverage grid caching solutions such as Oracle's Coherence. The actual implementation for Coherence is not available yet but is being worked on and we hope to attract other grid vendors to integrate their solutions as well. The approach taken allows you to leverage the grid as more then just a simple data cache. You should be able to leverage its distributed data porocessing capabilities for query execution and concurrency protection.
For the 1.1 release I hope to have an implementation that iullustrates how an alternate caching solution such as ehCache could be used. If interested in learning more please post a question to the users mailing list or newsgroup and we can get you connected with the developers working on the solution and the technical details necessary to use it.
I also recommend looking at our cache coordination support that is offerred out of the box. It addresses minimizing stale data in the cache in a clustered deployment.
Doug
r_sudh replied on Thu, 2008/07/03 - 3:12pm
From what I've read so far I haven't been able to figure out if JPA 2.0 will have a Criteria API.
Will EclipseLink 1.0 have a Criteria API or will it be included in a future release of EclipseLink as part of the JPA 2.0 implementation or as an extension?
sud
gyorke replied on Fri, 2008/07/04 - 8:41am
As mentioned in the Early Draft a critera API for JPA 2.0 is planned. Some of the API should be in the next Draft of the specification. I would rather not comment on the structure of the criteria API right now as the definition is in the very early stages.
--Gordon
Mike Keith replied on Fri, 2008/07/04 - 8:44am
in response to: r_sudh
Sud,
JPA 2.0 will have a Java-based expression language (sometimes called a "criteria API"). It will not be as powerful as the existing native TopLink expression API, but will offer all of the current functionality in JP QL, plus more as possible and appropriate. Although EclipseLink already includes support for a Java expression/criteria API, it will also include the new JPA 2.0 API once we have fully specified it. The EclipseLink API will continue to be offered, though, so you can use that now and migrate to the JPA version when it is specified and implemented.
-Mike
Donny A. Wijaya replied on Tue, 2008/07/08 - 10:33pm
djclarke replied on Wed, 2008/07/09 - 4:37am
in response to: fenrir
Donny,
Yes, all of the advanced features configured using annotations can also be done using XML.
For the example provided in the article I can have an EclipseLink-ORM.XML file containing:
Then when I wish to use it on a mapping:
In EclipseLink 1.0 these XML files can be used in place of the standard JPA ones or as overrides with just the advanced features specified to enable greater portability between vendors.
It is our goal to continue to drive the advanced features we have added based on user requirements back into future versions of the standards. I will leave it to our expert group memebers to comment on the specifics but you can also get more involved by providing feedback directly to the expert group and reviewing all of the drafts that they publish (http://www.jcp.org/en/jsr/detail?id=317).
Doug
r_sudh replied on Thu, 2008/07/10 - 2:32pm
Thanks for the response about the Criteria API. Can you shed some light on the integration with Teneo - the EMF to JPA persistence framework.
I'm investigating the feasibilty of an EMF - JFace Databinding - Teneo - EclipseLink - Derby stack for a rich client application and anything that makes this seamless/painless would be very helpful.
-sud
opastaja replied on Tue, 2009/10/27 - 2:01pm