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: <argument index="5"> <jpa:context unitname="foo"/> </argument> <property name="myUnit"> <jpa:context unitname="foo"/> </property> 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 <[email protected]> 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 <[email protected]> wrote: > >> Hi >> >> What about this index attribute that was added in jpa blueprint 1.1 >> schema? I've never seen an example on it. >> >> <xsd:complexType name="TunitType"> >> <xsd:attribute name="property" type="xsd:string" use="optional" /> >> <xsd:attribute name="index" type="xsd:string" use="optional" /> >> <xsd:attribute name="unitname" type="xsd:string" use="optional" /> >> </xsd:complexType> >> >> Thanks >> >> Lin >> >> >> On Thu, Nov 4, 2010 at 4:03 AM, Valentin Mahrwald >> <[email protected]> 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 >>> >>> >
