Hi Mike,
Is this change going to be made in the spec?
Thanks,
Sahoo
attached mail follows:
+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
>>>
>>>
>