Skip to main content

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

  • From: JJ Snyder <j.j.snyder@...>
  • To: users@...
  • Subject: [javaee-spec users] Re: Question about ejb modules
  • Date: Tue, 22 Oct 2013 13:08:08 -0400

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@...> 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@...>
To: users@...
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@...> 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@...>
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@...> 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@... or file a
JIRA
issue at https://java.net/jira/browse/GLASSFISH.

regards,

-Linda


Thanks,

John






[javaee-spec users] Question about ejb modules

John D. Ament 10/19/2013

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

Linda DeMichiel 10/21/2013

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

John D. Ament 10/22/2013

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

JJ Snyder 10/22/2013

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

John D. Ament 10/22/2013

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

JJ Snyder 10/22/2013

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

John D. Ament 10/22/2013

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

JJ Snyder 10/22/2013

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

Mark Struberg 10/22/2013

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

John D. Ament 10/22/2013

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

JJ Snyder 10/22/2013

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

Mark Struberg 10/22/2013
 
 
Close
loading
Please Confirm
Close