I hope not. Persistence jars should be just like any other library jar.
The problem in your example is that par.jar is not a persistence jar,
it's an ejb-jar. Perhaps the deployment tool should provide more feedback
when it is auto-discovering the component jar files.
Sanjeeb Kumar Sahoo wrote:
> Hi Mike,
> Is this change going to be made in the spec?
>
> Thanks,
> Sahoo
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: EAR scope persistence jar and classpath
> From:
> Qingqing Ouyang <Qingqing.Ouyang_at_Sun.COM>
> Date:
> Fri, 11 Nov 2005 10:23:55 -0600
> To:
> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>
> To:
> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
> CC:
> Mike Keith <michael.keith_at_oracle.com>,
> "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
>
>
> +1
>
> Sanjeeb Kumar Sahoo wrote:
>
>> Hi Mike,
>> After going through bugs like
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=77 I am taking a
>> slightly difference stance. From an ease of use point of view, we
>> should restrict EAR scoped persistence jars to lib directory only. I
>> shall give another example of making this mistake even more easily:
>>
>> app.ear // no application.xml
>> ejb.jar // contains classes with @Stateless, has an injected PU called
>> "em1"
>> par.jar // contains persistence.xml which defines a PU named "em1",
>> but this jar by mistake also contains a class with @Stateless
>>
>> Because of module discovery rules, par.jar is considered to be an
>> ejb-jar and hence it's PU is local to that ejb-jar -- contrary to what
>> user wanted. Hence the app would fail to deploy.
>>
>> More over, to be consistent with the *non-component* status given to
>> persistence jars, we should limit them to lib directory only. (I know
>> in my other email I asked the question as to why EAR scoped
>> persistence jar files can not be placed in any arbitrary directory
>> structure, but then after going thru' your response I think I was
>> wrong in comparing persistence jars with components).
>>
>> This definitely reduces complexities for users as well as for
>> container implementors (I am not biased by the later one because we
>> have already implemented it).
>>
>> Thanks & regards,
>> Sahoo
>>
>>
>> Mike Keith wrote:
>>
>>> Sahoo,
>>>
>>> The intent of this paragraph was to indicate that the classes
>>> in the persistence unit should be configured to be on the application
>>> classpath by the user, not by the Container. However, the more that
>>> persistence units appear to be like other type of Java EE modules
>>> (for example, if Bill Shannnon agreed to satisfy the previous
>>> question that you asked about allowing them to be in different
>>> directories from the root) then I feel that it might make more sense
>>> for the Container to place these jars on the application classpath
>>> (logically adding them to the lib dir).
>>>
>>> -Mike
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Sanjeeb Kumar Sahoo [mailto:Sanjeeb.Sahoo_at_Sun.COM]
>>>> Sent: Tuesday, November 08, 2005 7:15 AM
>>>> To: Mike Keith
>>>> Cc: persistence_at_glassfish.dev.java.net
>>>> Subject: EAR scope persistence jar and classpath
>>>>
>>>>
>>>> Hi Mike,
>>>> Referring to the latest packaging proposal (10/19), I see the following
>>>> is mentioned in section #6.2.
>>>> "All persistence classes defined at the level of the Java EE EAR
>>>> must be
>>>> accessible to all other Java EE
>>>> components in the application— i.e. loaded by the application
>>>> classloader— such that if the same entity
>>>> class is referenced by two different Java EE components (which may be
>>>> using different persistence
>>>> units), the referenced class is the same identical class."
>>>>
>>>> Is container responsible for making the EAR scoped persistence jars
>>>> available to all other components in the EAR even if user has not
>>>> explicitly specified a dependency on those jar files using Class-Path
>>>> manifest in individual component's manifest file? This indirectly means
>>>> they are treated as library jar files even though they are not
>>>> placed in
>>>> library directory of EAR file.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>>
>>