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 <[email protected]> > wrote: > >> With the current implementation you would use the blueprint handler instead >> of an argument / property rather than embedded in one. >> >> So >> >> <bean> >> <jpa:context unitname="foo" index="1" /> >> </bean> >> >> is "equivalent" to >> >> <bean> >> <argument index="1"> >> jpa internal gubbins for unit foo >> </argument> >> </bean> >> >> while >> <jpa:context property="prop" unitname="foo" /> >> >> will expand to >> >> <property name="prop"> >> jpa internal gubbins for unit foo >> </property> >> >> 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: >>> >>> <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 >>>>>> >>>>>> >>>> >>
