aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@apache.org>
Subject RE: jpa blueprint ns handler question
Date Fri, 05 Nov 2010 10:08:07 GMT

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"/>


Given this decision was made, when the requirement for constructor injection was raised the
index attribute was added for consistency. I feel this is a much better model, as we want
the JPA container to configure the injection metadata, not blueprint. It's also nice because
it's so concise for the main use cases, and also so immediately recognisable as a different
namespace.

As for arrays, collections and maps. If you can find a use case for this I'd be happy to support
it. I'd also be interested to know what it is, because this type of injection isn't supported
by Java EE and I've not heard anyone complain.

Regards,

Tim

----------------------------------------
> Subject: Re: jpa blueprint ns handler question
> From: vmahrwald@googlemail.com
> Date: Thu, 4 Nov 2010 20:06:36 +0000
> To: aries-dev@incubator.apache.org
>
> True. I wonder though if the extra flexibility is really needed. I can't really see a
scenario where one would want a EntityManager in a map or list. Whereas in the most common
use cases the current scheme saves two extra lines of xml :-)
>
>
> On 4 Nov 2010, at 15:49, Jarek Gawor wrote:
>
> > Yes, I understand how things are expanded now but that seems weird as the jpa ns
handler schema is replicating blueprint index, type, and name attributes. And on top of that
we can't inject persistence unit as part of list or map or array.
> >
> > Jarek
> >
> > On Nov 4, 2010, at 10:21 AM, Valentin Mahrwald  wrote:
> >
> >> With the current implementation you would use the blueprint handler instead
of an argument / property rather than embedded in one.
> >>
> >> So
> >>
> >> 
> >> 
> >> 
> >>
> >> is "equivalent" to
> >>
> >> 
> >> 
> >> jpa internal gubbins for unit foo
> >> 
> >> 
> >>
> >> while
> >> 
> >>
> >> will expand to
> >>
> >> 
> >> jpa internal gubbins for unit foo
> >> 
> >>
> >> Valentin
> >>
> >> On 4 Nov 2010, at 14:03, Jarek Gawor wrote:
> >>
> >>> That's another thing I've noticed and I wasn't sure it was because of
> >>> some blueprint ns handler limitations.
> >>>
> >>> I would expect to inject jpa unit or context like this:
> >>>
> >>> 
> >>> 
> >>> 
> >>>
> >>> 
> >>> 
> >>> 
> >>>
> >>> That way we should also be able to specify and inject a list or array of
PUs.
> >>>
> >>> I just can't recall if ns handler support in blueprint can support this
or not.
> >>>
> >>> Jarek
> >>>
> >>> On Thu, Nov 4, 2010 at 7:17 AM, Alasdair Nottingham  wrote:
> >>>> Hi,
> >>>>
> >>>> As I recall this was added to aid injection into constructors not to
identify which persistence unit to inject.
> >>>>
> >>>> Alasdair
> >>>>
> >>>> On 4 Nov 2010, at 11:03, Lin Sun  wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> What about this index attribute that was added in jpa blueprint
1.1
> >>>>> schema? I've never seen an example on it.
> >>>>>
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Lin
> >>>>>
> >>>>>
> >>>>> On Thu, Nov 4, 2010 at 4:03 AM, Valentin Mahrwald
> >>>>>  wrote:
> >>>>>> I think the assumption at the time of writing was that unit
names would be unique per framework, through isolating applications in sub-frameworks. As
far as the JPA spec goes there are no other useful properties to select on.
> >>>>>> We could introduce something like persistence bundle name and
persistence bundle version as properties on the service and possible selectors in the schema
!?
> >>>>>>
> >>>>>> Valentin
> >>>>>>
> >>>>>>
> >>>>>> On 4 Nov 2010, at 02:35, Jarek Gawor wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> From looking at the jpa blueprint ns handler, it seems like
the
> >>>>>>> handler only uses the unitname attribute to select which
persistence
> >>>>>>> unit to inject. But unitname alone might not be enough to
select the
> >>>>>>> right persistence unit. What if there are two different
persistence
> >>>>>>> bundles deployed with the same unit name? I think the schema
should
> >>>>>>> allow for an optional filter attribute which would be combined
with
> >>>>>>> the unitname to select the right persistence unit.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>> Jarek
> >>>>>>
> >>>>>>
> >>>>
> >>
>
 		 	   		  
Mime
View raw message