Kenneth Saks wrote:
>>
>>
>> No, there's still an ambiguity. To summarize, if there's one
>> persistence unit at the module level
>> and one at the .ear level and a @PersistenceUnit/_at_PersistenceContext
>> annotation within that
>> module that doesn't specify a unit name, what's the behavior?
>
This issue is resolved in the latest spec. It's A) That matches the
current
RI implementation so no change is needed.
>
>
> A) It resolves to the persistence unit within the module since the
> module level
> takes precedence and there's only one defined there.
> B) An error since there are a total of two visible persistence units
> and therefore
> a default cannot be determined.
>
>>
>>
>> Thanks,
>> Sahoo
>> Kenneth Saks wrote:
>>
>>>
>>>
>>> Sanjeeb Kumar Sahoo wrote:
>>>
>>>> Hi Ken,
>>>> Going thru' the change I am not able to understand how we are
>>>> shadowing unnamed persistence unit. What happens for the following
>>>> use case:
>>>>
>>>> app.ear
>>>> lib/par.jar
>>>> META-INF/persistence.xml has an *unnamed* PU.
>>>> ejb.jar
>>>> META-INF/persistence.xml has only one PU named *foo*.
>>>>
>>>> Which PU gets injected when some code in ejb.jar looks for an
>>>> *unnamed* PU?
>>>
>>>
>>>
>>>
>>> Good question, but I would reword this a bit since the application
>>> code isn't
>>> really looking for an "unnamed PU". It's just not specifying a
>>> unitName as a convenience
>>> when declaring the environment dependency.
>>> E.g. even in the old implementation, a @PersistenceContext
>>> annotation that doesn't specify
>>> unitName will work as long as there is only one .par in the .ear. It
>>> doesn't matter whether
>>> that .par was packaged as an unnamed .par or a named .par.
>>> Moving on the to real issue though, the wording from section 8.4 of
>>> the old spec says :
>>>
>>> "The unitName element refers to the name of the persistence unit.
>>> It must be specified if there is more than one persistence unit."
>>>
>>> I don't know whether this has been updated in the new spec since
>>> there is some
>>> ambiguity here now that there is a two-level precedence hierarchy.
>>> It's not clear
>>> whether "more than one persistence unit" refers to
>>>
>>> A) "within the module OR at the application level"
>>>
>>> With this interpretation, since the ejb-jar has a single PU and the
>>> ejb-jar
>>> takes precendence over the application-level, that's the one
>>> that is used for the environment dependency. This is the current
>>> implementation.
>>>
>>> B) "within the module AND at the application level combined" (in
>>> other words the total number of PUs visible from the module)
>>>
>>> With this interpretation, an environment dependency(within ejb-jar)
>>> that doesn't specify a unitName would be an error since there are a
>>> total of two PUs visible from the ejb-jar, one at the module level and
>>> one at the application level.
>>> C) within the entire .ear. This is unlikely since a PU defined in
>>> a .war that the ejb-jar has no visibility to wouldn't make much sense.
>>>
>>> Linda, which is it?
>>>
>>>>
>>>>
>>>> From the code I see we inject the PU called *foo*. Should we not
>>>> inject the *unnamed* PU defined in application level? That's what I
>>>> understood from the spec. May be my understanding is wrong.
>>>
>>>
>>>
>>>
>>>
>>>>