On 3/22/11 3:08 PM, Jason T. Greene wrote:
On 3/22/11 2:58 PM, David M. Lloyd wrote:
> On 03/22/2011 02:51 PM, David M. Lloyd wrote:
>> On 03/22/2011 02:42 PM, Andrig Miller wrote:
>>>> If OrderManagerEntities.jar is in the EAR's "lib" directory
(or the
>>>> directory you have configured as such in application.xml) then the
>>>> OrderManagerEJB.jar should be able to "see" it. If not then
you'll
>>>> need
>>>> an explicit "Class-Path" reference to it from your EJB JAR.
>>>
>>> No, my OrderManagerEntities.jar is not the EAR's "lib"
directory,
>>> its at the same level as the OrderManagerEJB.jar, and its listed as
>>> an EJB module in the application.xml.
>>>
>>> This seems broken to me.
>>
>> As a rule, we are restricting visibility by default as much as the spec
>> allows (which may mean certain behaviors are different from AS 5/6). So
>> the question is really, is this contrary to spec? If so, it's a bug.
>> That's what we need to answer.
>
> Here's the relevant passage:
>
> "Components in the EJB container may have access to the following
> classes and resources. Portable applications must not depend on having
> or not having access to these classes or resources.
> [...]
> * The content of any EJB jar files included in the same ear file.
> * The content of any client jar files specified by the above EJB jar
> files."
>
> Thus it is correct to require an explicit Class-Path between EJB JARs
> within an application.
Note that its typically not required if you are using injection / jndi,
because then you are wiring a dependency and passing instances along
module boundaries.
In the JPA case though, its just local classes, so their needs to be
some kind of import (/lib, class-path ref, module-ref) in our current
low-visibility model.
BTW the reason we went with the low-visibility model, was that our
thinking was it would reduce CCEs and allow for multiple EJB jars to use
different versions of a thirdparty framework in the same EAR.
--
Jason T. Greene
JBoss, a division of Red Hat