users@javaee-spec.java.net

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

From: JJ Snyder <j.j.snyder_at_oracle.com>
Date: Tue, 22 Oct 2013 09:56:08 -0400

I'm not sure what you mean by "scanned and added" but the CDI container
should resolve the resource, based on the meta information of the
injection point, and then inject the resource into that injection point.

So for example if I had a pojo in a library:
public class Pojo {
   @Resource( name="myDB")
   private javax.sql.DataSource myDb;

   public DataSource getMyDb() {
     return myDb;
   }
}

Then when this pojo is injected into something else like a servlet CDI
will create an instance of Pojo and inject the "myDB" datasource so that
it could be used in an example like:

public class MyServlet extends HttpServlet {
   @Inject
   Pojo pojo;

   public void service(HttpServletRequest req, HttpServletResponse res)
throws IOException {
     DataSource myDb = pojo.getMyDb();
   }

}

JJ
On 10/22/2013 09:09 AM, John D. Ament wrote:
> 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
>>>>>>>