users@javaee-spec.java.net

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

From: Mark Struberg <struberg_at_yahoo.de>
Date: Tue, 22 Oct 2013 18:09:34 +0100 (BST)

Oh, and I also made a small error 'Classes do only..' should be more clearly be stated as

"Classes _without bean defining annotations_ (aka CDI scopes or EJB stuff on the class) do only get picked up
by CDI in 'explicit bean archives' with bean discovery mode 'all'."

LieGrue,
strub




----- Original Message -----
> From: John D. Ament <john.d.ament_at_gmail.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: "users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>
> Sent: Tuesday, 22 October 2013, 18:51
> Subject: Re: [javaee-spec users] Re: Question about ejb modules
>
> Definitely.  It would obviously need to be a valid bean archive.
>
>
> On Tue, Oct 22, 2013 at 12:48 PM, Mark Struberg <struberg_at_yahoo.de> wrote:
>> I'm not sure if this example is good.
>>
>> If the Pojo class would have a scope which is known to CDI, then yes.
>> Otherwise it wont imo.
>> See the section about implicit bean modules. Classes do only get picked up
>> by CDI in 'explicit bean archives' with bean discovery mode
> 'all'
>>
>>
>> Means if the the Pojo in your sample is in a module without any beans.xml,
>> then CDI would inject nothing imo.
>>
>>
>> LieGrue,
>> strub
>>
>>
>> ________________________________
>> From: JJ Snyder <j.j.snyder_at_oracle.com>
>> To: users_at_javaee-spec.java.net
>> Sent: Tuesday, 22 October 2013, 15:56
>> Subject: [javaee-spec users] Re: Question about ejb modules
>>
>> 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
>>>>>>>>>
>>
>>
>>
>