Yea I made assumptions about beans.xml and was just giving the most
basic example...You have to follow all of the cdi rules of scoping and
what constitutes a valid bean archive, etc.
JJ
On 10/22/2013 12:51 PM, John D. Ament wrote:
> 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
>>>>>>>>>
>>
>>