[javaee-spec users] Re: Question about ejb modules

From: JJ Snyder <>
Date: Tue, 22 Oct 2013 09:05:27 -0400

cdi 1.1 spec mentions libraries in a couple of places:

Section 5.1 Modularity

Beans and their clients may be deployed in modules in a module
architecture such as the Java EE environment. In a module
architecture, certain modules are considered bean archives. In the Java
EE module architecture, any Java EE module or library
is a module. The Java EE module or library is a bean archive if it
contains a beans.xml file, as defined in Section 12.1.

Section 12.1 Bean archives
When determining which archives are bean archives, the container must
Library jars, EJB jars or application client jars

In an application deployed as an ear, the container searches every bean
archive bundled with or referenced by the ear, including
bean archives bundled with or referenced by wars, EJB jars and rars
contained in the ear. The bean archives might be library
jars, EJB jars or war WEB-INF/classes directories.

An embeddable EJB container searches each bean archive in the JVM
classpath that is listed in the value of the embeddable
container initialization property javax.ejb.embeddable.modules, or every
bean archive in the JVM classpath if the
property is not specified. The bean archives might be directories,
library jars or EJB jars.

On 10/22/2013 08:57 AM, John D. Ament wrote:
> JJ,
> Where in the spec is this indicated?
> John
> On Tue, Oct 22, 2013 at 8:39 AM, JJ Snyder <> wrote:
>> John,
>> Application libraries are processed by CDI.
>> JJ
>> On 10/21/2013 09:20 PM, John D. Ament wrote:
>>> Hi Linda,
>>> Thanks for the response.
>>> So for one, I guess what you are saying is that the intention is that
>>> an ejb-module, as defined within application.xml of an EAR file is
>>> intended to contain at least one EJB, but you seem to be implying that
>>> you don't think it's perfectly clear from the way the spec reads
>>> currently. I can enter an issue for this if you'd like. The one
>>> concern I have is that you're referencing an ejb-jar, but
>>> application.xml only really has a reference to an ejb-module.
>>> the other half of the issue is that there is no way, right now, to
>>> define a JAR file that just contains CDI beans. I think this is more
>>> evident with Java EE 7 where CDI beans can actually be used almost
>>> entirely throughout an application, especially with the addition of
>>> transaction services. I think the platform spec needs to consider an
>>> enhancement to application.xml to support a
>>> <bean-archive>path/to/jar</bean-archive> entry that indicates this is
>>> a bean archive within the scope of an EAR file, unless it's expected
>>> that CDI beans should be scanned from the lib folder of an EAR.
>>> Thoughts?
>>> John
>>> On Mon, Oct 21, 2013 at 6:45 PM, Linda DeMichiel
>>> <> wrote:
>>>> On 10/19/13 7:54 AM, John D. Ament wrote:
>>>>> Experts,
>>>>> I ran into an interesting issue on GlassFish 4, which I hadn't seen
>>>>> before in other application servers. It appears that if I want to
>>>>> deploy an EAR, I cannot put CDI beans into a standalone module, expect
>>>>> it to be scanned and added to the application.
>>>>> Previously, I had used a trick by marking the module as an EJB module
>>>>> it would scan for CDI beans and make them available within my EAR.
>>>>> Now ignoring the CDI scoping issues at play, I am seeing an error come
>>>>> back from GlassFish 4 stating that an EJB module must contain at least
>>>>> one session bean/entity bean/MDB.
>>>>> Is this expected? If so, which spec actually defines this behavior? I
>>>>> was having a hard time finding it.
>>>> John,
>>>> Thanks for your post.
>>>> While the EJB spec should have been more explicit as to whether an
>>>> ejb-jar file must contain EJB beans, I think it is safe to say
>>>> that this is the intention of the spec. For example, see section 15.1:
>>>> "An ejb-jar file produced by the Bean Provider contains one or
>>>> more enterprise beans that typically do not contain application
>>>> assembly instructions. The ejb-jar file produced by an Application
>>>> Assembler (which can be the same person or organization as the
>>>> Bean Provider) contains one or more enterprise beans, plus
>>>> application assembly information describing how the enterprise
>>>> beans are combined into a single application deployment unit."
>>>> Please file a JIRA issue at, so
>>>> that we can track this item for purposes of discussion and clarification
>>>> in the next release.
>>>> As to the GlassFish behavior, my understanding is that GlassFish
>>>> introduced the error-checking for this case back in the Java EE 5 days.
>>>> For further follow-up with our GlassFish team, please post with more
>>>> details about your use case to or file a JIRA
>>>> issue at
>>>> regards,
>>>> -Linda
>>>>> Thanks,
>>>>> John