On Oct 3, 2006, at 7:44 AM, scabooz wrote:
Hi Jim,
Somewhere buried in your explanation is the answer to
my question, but I can't find it, so I'll have to ask. I'm
trying to understand how you have modeled this WRT
the assembly model. It looks like you've added in a
SCDL extension, and are playing with the semantics
of a property. I would have expected such a formal
part of the application to have been modeled in a
formal way, such as with an SCA component.
It's a property (or "resource") just like a datasource or type system
helper (e.g. SDO) would be. Modeling it as a service on a component
seems kind of odd. There's a system service responsible for providing
a value for the property (just like all property values in Tuscany)
but that's an implementation detail. Make sense?
Am I
understanding this correctly? I'm asking from a spec
perspective, trying to make sure that we're clean.
Dave
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 03, 2006 4:00 AM
Subject: Re: EJB3 (JPA) support
Hi Meeraj,
I checked in some minor changes to the JPA extension. I was
thinking things would work along the following lines:
- An application developer could specify a JPA persistence context
in their assembly using an <import.jpa name="">.
- JPAImportLoader would process <import.jpa> and resolve JPA
artifacts (persistence.xml, mapping files, etc.). It may need the
composite classloader to do this or come up with a better
mechanism (I'm too tired to really think about it now).
JPAImportLoader would also create an model of a JPA system
service which would be used by constructed by
JPAComponentBuilder to create a JPAAtomicComponent. The builder
would register this system service in the parent (application
composite) tree.
- There would be an EntityManagerProcessor registered in the
*runtime* (as opposed to the application) system tree. When a
user component marked with @PersistenceContext is encountered,
EntityManagerProcessor would create a property and populate the
component type. the property would have a
EntityManagerObjectFactory which is responsible for injecting
entity managers on the implementation instance.
EntityManagerProcessor would call resolveSystemInstance() on the
parent application composite and get the EMF, passing it to an
EntityManagerObjectFactory. The latter would then be set as the
default object factory on the property.
- When the user component is instantiated, the
EntityManagerObjectFactory will call to the EMF and create an
EntityManager.
I started skeleton work to support this but most of the hard stuff
is missing. For example, I believe we are going to need to figure
out dependency classloading as both the runtime system
EntityManagerProcessor and application components need access to
JPA classes. I probably haven't explained this very well, but
maybe you could take a look at the skeletal code and we could go
from there?
I definitely think we should draw inspiration from what Spring did
in terms of integration. For example, we will probably need to
figure out how to support persistence contexts that span more
than a transaction. Once we get a basic working extension, we may
want to look at plugging this into a transaction manager, which
we'll need for policy support.
Jim
On Oct 2, 2006, at 11:51 PM, Meeraj Kunnumpurath wrote:
I will take a look Jim and try to assist, I have been doing a bit
recently at work with Hibernate JPA and the Spring 2.0 JPA
support. May
be we can draw some inspiration from Spring 2.0 as well.
Ta
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 03 October 2006 07:46
To: [email protected]
Subject: Re: EJB3 (JPA) support
Yep. I'm working on some minor things to the JPA extension now and I
should have them checked in soon (hour or so). I'm still figuring
out
how this stuff is going to work (I'm more familiar with the
Hibernate
API than JPA) but perhaps when I do the check in I can send
another note
describing the changes and you can have a look to see if it
makes sense,
and maybe take it forward a bit? I think the Hibernate API one
should
work similarly.
Jim
On Oct 2, 2006, at 11:36 PM, Meeraj Kunnumpurath wrote:
Do you mean the Hibernate session API without using the entity
manager?
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 02 October 2006 20:30
To: [email protected]
Subject: Re: EJB3 (JPA) support
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]
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for the
exclusive use
of the addressee only. You should not disclose its contents to any
other person.
If you are not the intended recipient please notify the sender
named
above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
-------------------------------------------------------------------
--
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]
This message has been checked for all email viruses by MessageLabs.
This message has been checked for all email viruses by MessageLabs.
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
