I think there are two aspects here, 1. Injecting an entity manager factory (using @PersistenceUnit annotation on a property) 2. Injecting an entity manager (using @PersistenceContext annotation on a property)
The first one is pretty straight forward as the binding is load time and pretty straight forward. We could have something that looks at properties annotated with the PersistneceUnit annotation at load time and scan the current classloader and parents for any persistence.xml files with a matching persistence unit name. From the XML, we can find the provider class for the JPA implementation and use that configure the entity manager factory and inject the reference to the component. The second one is more tricky, entity manager instances are dynamically bound based on the transaction scope and may require the policy framework to create and inject a reference on a per invocation stack basis. This could use the relavant entity manager factory that is made available as a system service. Lot of these things are generic and should be common for any JPA implementation. From that perspective, I am not sure whether we need specialized modules for OpenJPA, Hibernate, Toplink etc. Most of the customizations of the runtime behaviour and configuration will be within the persistence.xml file. Jim, I would be interested in knowing your views on this. I wouldn't mind starting a look at implementing support for PersistenceUnit annotation for a start based around the stuff Jim checked in. Ta Meeraj >> -----Original Message----- >> From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> Sent: 03 October 2006 21:05 >> To: [email protected] >> Subject: Re: Modeling persistence services, was Re: EJB3 >> (JPA) support >> >> I see wires in the assembly as representing the interaction >> between application components. Properties on the other hand >> represent a contract between the application component and >> the container (by which I mean the container is responsible >> for configuring an instance of the application component >> with the value of that property). >> >> One way to represent an EntityManager would be to add a >> component to the system that exposed that as a service. You >> could then wire components to it as normal. >> >> That does seem a little odd to me in that you would probably >> need a custom implementation type for such a component that >> allowed you to specify the EntityManagerFactory >> configuration. It also seems odd to be using EntityManager >> as a service interface (valid, but odd). >> >> Less odd to me is the idea of things (like EntityManager) >> that are services provided by the runtime environment where >> a component is running. They are part of a contract between >> an implementation and its environment rather than between an >> implementation and another component. We have that concept >> already in the form of Property (contract with the >> environment to instantiate a value) so extending that >> concept to more complex things would seem natural. >> >> This would allow me to change the implementation type for >> the component without changing the business level services >> that it connects to. I can swap the implementation from one >> that uses JPA to one that uses JDO or JDBC or XML or C++ >> with ODBC without removing/ adding other components to my assembly. >> >> Being of the "cake and eating it camp" I think we should do both: >> * provide <implementation.jpa> that can be used to define a >> component with an EntityManager service interface >> * support properties with a type of "EntityManager" that can >> be injected to a component >> >> The same would go for other similar things such as SDO >> Helpers, JDO PersistenceManagers, ... >> -- >> Jeremy >> >> On Oct 3, 2006, at 9:29 AM, scabooz wrote: >> >> > Hmmmm...a service modeled as a property is what seems odd. >> I'm trying >> > to keep an open mind. >> > Imagine drawing a picture of this using the icons from the >> SCA spec. >> > You'd have some kind of a connection from a component's >> property to a >> > database? That's what doesn't make sense. I need to >> think more on >> > this, and maybe I'll change my mind. Didn't want to let >> this thread >> > just die. >> > >> > Dave >> > >> > ----- Original Message ----- From: "Jim Marino" >> > <[EMAIL PROTECTED]> >> > To: <[email protected]> >> > Sent: Tuesday, October 03, 2006 11:40 AM >> > Subject: Re: EJB3 (JPA) support >> > >> > >> >> 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 >> >>> >> > >> > <snip> >> > >> > >> > >> --------------------------------------------------------------------- >> > 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]
