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
>>>>>>>>
>
>
>