You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/11/04 03:35:08 UTC
jpa blueprint ns handler question
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
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
I don't think we can expect every framework to support isolation. So I
think we should expose the persistence bundle name & version as the
service properties and modify the ns handler schema to allow for more
precise query. I would prefer a generic filter attribute instead of a
specific properties for bundle name and/or version.
Jarek
On Thu, Nov 4, 2010 at 4:03 AM, Valentin Mahrwald
<vm...@googlemail.com> 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
>
>
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Nov 10, 2010 at 2:40 PM, Timothy Ward <ti...@apache.org> wrote:
>
> I'm afraid I simply don't agree that the proposed syntax is better. The 99% use case for JPA is to inject a persistence unit or context via a setter method, and this is the case that needs to be optimised. Forcing users to add property elements around the JPA elements unnecessarily complicates this scenario.
If a blueprint developer wants to inject a list or a bean, etc. as a
property or argument, he/she puts the value within the <property> or
<argument/> elements. Any blueprint developer knows that. So this is
nothing new or complex about it. And in fact when you go outside of
this convention things become unfamiliar and unexpected. So this
"optimization" has quite the opposite effect to me.
Jarek
RE: jpa blueprint ns handler question
Posted by Timothy Ward <ti...@apache.org>.
I'm afraid I simply don't agree that the proposed syntax is better. The 99% use case for JPA is to inject a persistence unit or context via a setter method, and this is the case that needs to be optimised. Forcing users to add property elements around the JPA elements unnecessarily complicates this scenario.
You are right to say that argument and property injection is well defined by the blueprint specification, which is why the JPA Namespace Handler uses the standard runtime model to describe the injection. The namespace handler hasn't invented anything here, it simply provides a more concise specification of the standard xml.
As for reducing the complexity of the NamespaceHandler code, I firmly believe that it is better to have slightly more complex code in order to reduce the complexity for every user.
Regards,
Tim
----------------------------------------
> Date: Wed, 10 Nov 2010 13:35:52 -0500
> Subject: Re: jpa blueprint ns handler question
> From: jgawor@gmail.com
> To: aries-dev@incubator.apache.org
>
> On Mon, Nov 8, 2010 at 12:27 PM, Alasdair Nottingham wrote:
> >
> > I was specifically referring to your comment about one form making more sense than another. I was pointing out that which is simpler or clearer and depends on what you think jpa:context means. I was not commenting on the relative validity of the two XML snippets.
> >
>
> Ok. To me the question is, what fits better or is more natural from
> Blueprint POV? The syntax I described fits much better with Blueprint,
> it's consistent, flexible, etc. Even one of the jpa blueprint users
> had the right idea in ARIES-413.
>
> The argument and property bean injection is well defined in the
> blueprint spec and we shouldn't invent our own ways of doing the same.
> The current namespace handler just does too much and if we switch to
> the new syntax the code and schema will be simpler and we will have
> greater flexibility.
>
> Jarek
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
On Mon, Nov 8, 2010 at 12:27 PM, Alasdair Nottingham <no...@apache.org> wrote:
>
> I was specifically referring to your comment about one form making more sense than another. I was pointing out that which is simpler or clearer and depends on what you think jpa:context means. I was not commenting on the relative validity of the two XML snippets.
>
Ok. To me the question is, what fits better or is more natural from
Blueprint POV? The syntax I described fits much better with Blueprint,
it's consistent, flexible, etc. Even one of the jpa blueprint users
had the right idea in ARIES-413.
The argument and property bean injection is well defined in the
blueprint spec and we shouldn't invent our own ways of doing the same.
The current namespace handler just does too much and if we switch to
the new syntax the code and schema will be simpler and we will have
greater flexibility.
Jarek
Re: jpa blueprint ns handler question
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair Nottingham
On 8 Nov 2010, at 17:02, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 5:05 PM, Alasdair Nottingham <no...@apache.org> wrote:
>>
>>
>> Alasdair
>>
>> On 5 Nov 2010, at 20:16, Jarek Gawor <jg...@gmail.com> wrote:
>>
>>> On Fri, Nov 5, 2010 at 6:08 AM, Timothy Ward <ti...@apache.org> 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.
I was specifically referring to your comment about one form making more sense than another. I was pointing out that which is simpler or clearer and depends on what you think jpa:context means. I was not commenting on the relative validity of the two XML snippets.
>
> Jarek
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Nov 5, 2010 at 5:05 PM, Alasdair Nottingham <no...@apache.org> wrote:
>
>
> Alasdair
>
> On 5 Nov 2010, at 20:16, Jarek Gawor <jg...@gmail.com> wrote:
>
>> On Fri, Nov 5, 2010 at 6:08 AM, Timothy Ward <ti...@apache.org> 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.
Jarek
Re: jpa blueprint ns handler question
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair
On 5 Nov 2010, at 20:16, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 6:08 AM, Timothy Ward <ti...@apache.org> 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.
My view has always been that it is the equivalent of the @PersistenceContext annotation, so I like the scheme as is, and it makes sense and is clear.
Alasdair
>
> Jarek
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Nov 5, 2010 at 6:08 AM, Timothy Ward <ti...@apache.org> 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.
Jarek
RE: jpa blueprint ns handler question
Posted by Timothy Ward <ti...@apache.org>.
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
> >>>>>>
> >>>>>>
> >>>>
> >>
>
Re: jpa blueprint ns handler question
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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 <vm...@googlemail.com> 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 <no...@apache.org> 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 <li...@gmail.com> 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
>>>>> <vm...@googlemail.com> 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
>>>>>>
>>>>>>
>>>>
>>
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
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 <vm...@googlemail.com> 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 <no...@apache.org> 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 <li...@gmail.com> 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
>>>> <vm...@googlemail.com> 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
>>>>>
>>>>>
>>>
>
Re: jpa blueprint ns handler question
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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 <no...@apache.org> 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 <li...@gmail.com> 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
>>> <vm...@googlemail.com> 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
>>>>
>>>>
>>
Re: jpa blueprint ns handler question
Posted by Jarek Gawor <jg...@gmail.com>.
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 <no...@apache.org> 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 <li...@gmail.com> 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
>> <vm...@googlemail.com> 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
>>>
>>>
>
Re: jpa blueprint ns handler question
Posted by Alasdair Nottingham <no...@apache.org>.
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 <li...@gmail.com> 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
> <vm...@googlemail.com> 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
>>
>>
Re: jpa blueprint ns handler question
Posted by Lin Sun <li...@gmail.com>.
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
<vm...@googlemail.com> 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
>
>
Re: jpa blueprint ns handler question
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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