aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: jpa blueprint ns handler question
Date Mon, 08 Nov 2010 17:02:09 GMT
On Fri, Nov 5, 2010 at 5:05 PM, Alasdair Nottingham <> wrote:
> Alasdair
> On 5 Nov 2010, at 20:16, Jarek Gawor <> wrote:
>> On Fri, Nov 5, 2010 at 6:08 AM, Timothy Ward <> wrote:
>>> To clarify, the aim when designing this function was to make consuming persistence
units and contexts as simple as possible - hence trying to make sure that it could be expressed
as a single element.
>>> The primary injection mechanism people use is by setters, which in blueprint
would be something like:
>>> <property name="foo" ref="bar"/>
>>> In order to get JPA to be similarly concise, and to avoid breaking the existing
validation requirements of Blueprint, we came up with the <unit/> and <context/>
tags, which contain the information from an @PersistenceContext and @PersistenceUnit annotation.
>>> The decision was made that:
>>> <property name="emf" type="javax.persistence.EntityManagerFactory">
>>>   <jpa:unit unitname="myUnit"/>
>>> </property>
>>> was significantly less usable than:
>>> <jpa:unit property="emf" unitname="myUnit"/>
>> I disagree. To me the following is much clearer:
>> <property name="emf">
>>  <jpa:unit unitname="myUnit">
>> </property>
>> And this syntax is consistent with rest of the blueprint syntax, i.e.
>> how you would inject a bean as a property or argument. The <jpa:unit/>
>> and <jpa:context/> provide a specific object just like a <bean/> or
>> <reference/>, etc. and should be handled in the same way, IMHO.
> It depends on what you consider jpa:context is doing. I you think it defines a bean that
is an entity manager then I understand your point, if you consider it the equivalent of @PersistenceContext
then I think the scheme as is makes sense.

I'm not really sure what you mean by that. The current ns handler
either injects a <reference/> (for EntityManagerFactory) or a <bean/>
(for EntityManager)...
I think we should also consider that this is Blueprint injection. It
has different rules than Java EE, e.g. it supports array or list
injection, etc. We should ensure that our solutions take advantage of
these differences. We shouldn't limit ourselves to what is possible or
not in Java EE.


View raw message