On Dec 14, 2009, at 2:55 AM, Alessandro Bottoni wrote:
> Hi All,
> I'm looking at the alternatives that are available for building the
> persistence layer of a application in Tapestry 5 and I would be happy to
> hear your opinion about a couple of topics:
>
> 1) I see that there is a support library for JPA and JPA2
> (http://kenai.com/projects/tapestry-jpa) but the description page at
> Kenai says that the project was started on september 2009 so I wonder:
> Is this library already mature and usable, even for production?
The project was started then, but piero had been using his library in
production for while.
Neither tapestry-jpa or taptestry-hibernate are a lot of code. Tapestry-jpa
comes in two flavors. All the work is being done on tapestry-jpa2, which is
using the new stuff in JPA2 to make tapestry-jpa2 mostly feature complete with
tapestry-hibernate in terms of having EntityValueEncoders and a GridDataSource.
So:
tapestry-jpa: Stable, not going to change, uses JPA 1.0
tapestry-jpa2: Slightly in flux. Has some new stuff which uses JPA 2.0,
which is the only way to build some of the things that tapestry-hibernate
provided. It wasn't working with EclipseLink a while back due to what looked
liked a bug in EclipseLink-2.0-SNAPSHOT, but I haven't tried it recently. It's
working ok for me using Hibernate-3.5.0-SNAPSHOT as my JPA persistence
provider.
>
> 2) Is it better to use JPA/JPA2 or Hibernate3 with Tapestry 5? Why?
> (I would probably stick with Hibernate but I'm open to suggestions.)
I'm kind of a noob, even though I'm one of the people working on
tapestry-jpa.
Here's my opinion, which may be partially misinformed, hopefully people will
correct me as necessary.
For both JPA/Hibernate, you have two ways to go:
1. Container-Managed EntityManagers and transactions.
By this I mean that you're using @PersistenceContext and such in your classes
so that your web application container (i.e. GlassFish) manages the
EntityManagers and the transactions. The Tapestry jumpstart uses this approach.
Advantages:
You can access more than one persistence unit.
Possibly the Container can do smart stuff like EntityManager pools?
Transaction stuff happens automatically and mysteriously for you.
Very much standardized.
Disadvantages:
No EntityValueEncoder that "remembers" entities in the session by just
remembering their primary key. (Though you could make one easy enough I
suspect).
No GridDataSource
2. Tapestry-Managed
2a. tapestry-hibernate
2b. tapestry-jpa
In this case, you're using @Inject to inject Sessions/EntityManagers as
needed. You annotate methods with @CommitAfter when you want transactions
committed.
Advantages:
Because you tell Tapestry up front about your single database
connection, it can build EntityValueEncoder and GridDataSources that can pull
in your objects as necessary.
Disadvantages:
You can only use one database connection.
You have to be more explicit about what does what in your application.
You'll have to do one thing for Tapestry, one thing for standalone
code.
Summary:
You can just use the JPA annotations as is with Tapestry, and the
container does the work.
If you want, you can use tapestry-jpa and tapestry-hibernate. They have
a few more features you might find useful, but they lock you into one database
connection. Then the Tapestry container is doing the work instead.
Pierce
The boundaries of my ignorance:
While I'm relatively new to Tapestry/JPA/Hibernate, I've been a WebObjects
guy for 12+ years now. I'm just now moving into T/J/H because in my opinion,
its just now that the existing tools have passed WebObjects which figured out
most of these problems years ago. It's just that WO is getting stale, and the
containers have gotten better such that its now really obvious that
GlassFish/Tapestry/JPA is the best technology out there.
But its all relatively new to me. I started working on tapestry-jpa2 because
it seemed to me that it was the best way to integrate JPA with Tapestry. Now
I'm not so sure that cloning tapestry-hibernate was the right approach.
Tapestry-hibernate is an IoC provider to build Hibernate sessions as needed,
but the JPA guys already thought of this issue, so why not use the IoC stuff
built into the container?
That is, I'm starting to think that the existing @PersistenceContext stuff is
preferable to @Inject because its more flexible. So what makes more sense is to
implement JPAGridDataSource as something that uses the JPA annotations instead,
but to do that I have to understand the JPA/Container IOC vs. the Tapestry IOC
a bit better, because one problem with @PersistenceContext is that it takes a
static string for the name to inject. So JPAGridDataSource would have to be an
abstract superclass and you would then have to build a concrete subclass for
each persistence unit. Which would be trivial.
But that's not going to happen quickly, unless someone volunteers to mind
meld with me over Skype. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
