james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [imap] Java 1.5...? + JCR vs JPA implementation
Date Tue, 06 Jan 2009 22:24:36 GMT
Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com] wrote on: 06
January 2009 19:53
> On Tue, Jan 6, 2009 at 12:22 AM, hanasaki
> <hanasaki@hanaden.com> wrote:
> > Interesting comment below on the use of JCR (hierarchical
> schemata) or a JPA
> > implementation. (RDBMS)
> >
> > What would you consider the pro/con argument of one vs the other?
> the way i see things:
> JCR is more document-centric. this makes integration with
> document-centric applications easier.
> JPA integrates better with traditional RDBMS applications.
> but other people may well have other perspectives...
> - robert

It's horses for courses. A JPA 1.0 implementation is a 'traditional'
object/relational mapping layer (ORM), while a JCR (JSR 170) implementation
has layers of functionally atop this. A JCR implementation most often uses
an underlying RDBMS as its persistent store, but is not required to. It
might even use JPA; one shouldn't care as the persistent store is
transparent at the JCR API level.

When the additional layers of functionality JCR provides are beneficial it
makes sense to use them, why reinvent the wheel? When they aren't, JPA is
enough. For James, where we have discrete data stores for particular
functions, it seems sensible to use the most appropriate solution for each
data store.


Both the JCR and JPA specs. leave several areas open which implementations
have filled in their own way. For instance, the Apache Jackrabbit JCR adds
much useful functionality beyond JSR 170, such as content searching using
Lucene which James could exploit. JPA implementations such as EclipseLink
(formerly TopLink), Hibernate and OpenJPA each have their own extensions or
best guesses at the final JPA 2.0 requirements. EclipseLink is the best
guess as it is the JPA 2 reference implementation.

Should we use these extensions, thereby binding us to a specific
implementation rather than the specs.? I would say yes when the alternative
is again to reinvent the wheel by coding around limitations in the specs.
ourselves, but limit this to features proposed for the new specs.; JSR 283
in the case of JCR, and JSR 317 in the case of JPA 2. It isn't that I think
these specs. are the greatest, but we should focus on problems in our mail
domain and choose the best solutions from those solving problems in other
domains such as content management and persistence stores.


-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message