Ok, thanks.
And just to confirm, what you're saying is that if a class in a lib
has an @Resource injection point, and that class itself is considered
part of a bean archive in the lib of an EAR, it should be properly
scanned and added, correct?
Thanks,
John
On Tue, Oct 22, 2013 at 9:05 AM, JJ Snyder <j.j.snyder_at_oracle.com> wrote:
> John,
> 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
> consider:
> 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.
>
>
> JJ
>
> 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 <j.j.snyder_at_oracle.com> 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
>>>> <linda.demichiel_at_oracle.com> 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 https://java.net/jira/browse/EJB_SPEC, 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 users_at_glassfish.java.net or file a JIRA
>>>>> issue at https://java.net/jira/browse/GLASSFISH.
>>>>>
>>>>> regards,
>>>>>
>>>>> -Linda
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> John
>>>>>>
>