On Oct 2, 2006, at 11:35 AM, Meeraj Kunnumpurath wrote:
Jim,
From your reply, I think the key is injecting in a persistence
unit. Hibernate has an EJB 3.0 implementation (both the OR
annotations and the entity manager). This will work pretty much the
same as open JPA (or any closed JPA :-), sorry couldn't resist it)
Yes I think we want to have a generic integration if possible so we
can use ClosedJPA too ;-) There may be some customizations we need
for particular vendor impls.
May be we can have a framework that can support any JPA
implementation make the EMF available as a system service.
Yes agreed, although we may not want to say "EMF" since that may
confuse people with Eclipse Modeling Framework :-) I'd also like to
get a Hibernate integration going for people that like that API.
Jim
Ta
Meeraj
From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: EJB3 (JPA) support
Date: Mon, 2 Oct 2006 10:30:20 -0700
Sure (since both you and Meeraj asked)...
Basically, I think the use cases are pretty much the same for
JPA, Hibernate, or JDO (not surprisingly): an application
developer wants to use a strongly-typed O/R mapper to persist
data used within a service or composite implementation. They
should be able to use any of the JPA annotations to inject an
entity manager onto a service instance:
public class FooImpl extends Foo {
@PersistenceUnit(name="example")
protected EntityManager entityManager;
}
Hibernate would work the same way, except inject a Session. This
would basically be an example of the "layering" approach to Java
C&I that we have discussed in the spec group. Under the covers,
Tuscany is managing instances of EntityManagerFactory as system
services and there is an annotation extension which is
responsible for performing the injection of EntityManager
instances (non-thread-safe) onto component implementation instances.
I would expect developers to use this approach when:
- writing in Java or perhaps a "Java-friendly" language such as
Groovy (obviously!)
- they don't need to perform batch-oriented operations (JDBC is
better for that)
- they want to manipulate data in an O-O fashion as opposed to in
a loosely typed way or something like active record
- they don't want to use declarative services, or they are not
suited for an application's needs
- they just like JPA or Hibernate for whatever reason
From a non-technical perspective, this helps to embrace several
communities by showing how their technologies are relevant in an
SCA environment.
Jim
On Oct 2, 2006, at 8:00 AM, scabooz wrote:
Hi Jim,
This is the first time I've seen this topic discussed on the
list. Apologies
if I've missed it previously. Can you illuminate some of your
thinking behind it? I'm interested in understanding the use
cases you
might be thinking of supporting, from at least the
perspective of the app developer.
thanks
Dave Booz
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 02, 2006 3:24 AM
Subject: EJB3 (JPA) support
Hi,
I checked in a skeleton of EJB3 persistence support (using
OpenJPA) that will leverage the system service work I just
did. If anyone is interested in helping with this or adding
in Hibernate support let me know. We may want to look at
providing a generic EJB3 JPA extension, although I'm not sure
how much common code would exist across implementations.
Jim
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Get today's hot entertainment gossip http://movies.msn.com/movies/
hotgossip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
