JBOSS EAP 6 Series four EJB Implementation-invoke (module through always)

This article focuses on how modules in JBoss EAP 6.2 (or JBoss AS7) have been implemented throughout the EJB. Continuation of the topic "Understanding the use of modules" continue to talk about JBoss as a module declaration container of this feature in the EJB implementation of the full implementation.

Session Bean

The default EJB in JBOSS EAP (AS7) is the 3.1 version that follows the JSR318 specification. EJB has fully introduced the concept of annotation from 3.0 onwards, and 3.0 of the previous EJBS need to implement the configuration of the bean in the XML file in the code by way of tags. At the same time, the dual-interface home and remote, previously made for Factory mode, have been replaced by a business interface. Since the concept of the entity bean has been taken out of the EJB and placed in the JPA specification, this article only introduces the implementation of the most basic annotation method of session bean, and provides the knowledge base for the later article.

The Session bean consists of two parts: a business interface and a Java class that implements the business specifically.

The business interface is a common Java interface interface.
Can be declared as @local or @remote, the difference is to indicate the visibility of this EJB.
@Local indicate that this is a session bean that is visible only within the same container scope
@Remote can call this session bean whenever it can communicate with this host.

<span style= "FONT-SIZE:18PX;" >public interface Assesscontentbean extends basebean<assesscontent> {public list<assesscontent> Querycontentbytemplateid (String TemplateID);p ublic boolean deleteAll (object[] IDs);} </span>

Implementation class is a common Java class

Use @stateless or @stateful above the class name to indicate whether the session bean has a state.

The name attribute in the @Stateless or @stateful tag can be used to indicate the Jndi name of the stateless bean, and if it is not specified, it is the Jndi name of the implementation class.

A little change to note is that unlike EJB3.0, EJB3.1 's Jndi has a big change, originally @stateless in EJB3.0 (name= "Studentassessresultbeanimpl"), The bean can be found on the client using Initcontext.lookup ("Studentassessresultbeanimpl").

But the JNDI specification for EJB3.1 is

Java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-quali? Fied-interface-name>]

Where the war package name App-name,jar package name Module-name, the custom bean name Bean-name, the interface's full address name Fully-quali?fied-interface-name.

so as stated in @stateless (name= "") in the new EJB3.1 Jndi is only the <bean-name> part, want to call this EJB also need to combine all the names, The specific Jndi name is described in the following blog post.

Directly on the simplest instance of a stateless bean:

<span style= "FONT-SIZE:18PX;" > @Stateless (name= "Studentassessresultbeanimpl") @Remote (Studentassessresultbean.class) @TransactionManagement (Transactionmanagementtype.container) @TransactionAttribute (transactionattributetype.required) public class Studentassessresultbeanimpl extends basebeanimpl<studentassessresult> implements Studentassessresultbean {@ EJB (beanname = "Studentassessresulteao") private Studentassessresulteao Studentassessresulteao; @Overridepublic Baseeao Getbaseeao () {//TODO auto-generated method Stub23return This.studentassessresulteao;}} </span>

This is the simplest implementation of the EJB, which can be run for the previous JBoss as, but JBoss EAP 6.2 (or JBoss AS7) needs to be configured for the EJB, which is described in the next section.

"EJB Learning content small extension"

Here are some of the most commonly used tags, and it's enough to learn most of them.

@Stateless
@Remote
@Local
@LocalBean
@EJB
@Resource
@Inject
@Stateful
@Init
@PostConstruct
@PreDestroy
@PrePassivate
@PostActivate
@Remove

As for the EJB complex implementation technology is not introduced, to understand in-depth can download the EJB 3.1 specification JSR318.

All of the above are the service-side EJB code, the client side in the next post, "Let people love and hate EJB3.1 Jndi" Introduction Jndi will be more in-depth introduction.

2. always-on modulesback to the topic of the module, the specific configuration of the module is described in section 2nd, "Configuring the Oracle Data Source-Understanding module". This section uses an example in production to illustrate how the module is always used throughout the EJB implementation process.

Review the features of the "Module declaration container" described in the first article of this series, "new Features":
JBOSS EAP no longer has the concept of lib, everything is module. Either the Lib of the system call, the user-compiled Lib, or the third-party lib that the application refers to is built in a modular way, and where it is used, it is declared which module is used.

<span style= "FONT-SIZE:18PX;" > @Stateless (name= "Studentassessresultbeanimpl") @Remote (Studentassessresultbean.class) @TransactionManagement (Transactionmanagementtype.container) @TransactionAttribute (transactionattributetype.required) public class Studentassessresultbeanimpl extends basebeanimpl<studentassessresult> implements Studentassessresultbean {@ EJB (beanname = "Studentassessresulteao") private Studentassessresulteao Studentassessresulteao; @Overridepublic Baseeao Getbaseeao () {//TODO auto-generated method Stub23return This.studentassessresulteao;}} </span>

With the foreshadowing of the previous section, the above truncated code basically shows the structure of the entire component, which is a logging component in the product, including 3 parts:

• Logmanager is a concrete implementation of EJB, the above code is intercepted from the Logmanager.
• Logmanagercommon is where EJB stores interfaces, and places public methods and variables related to log calls and storage. Logmanger need to rely on this project
• Commonclass is used to place various resources within the global scope of the project. Logmanger and Logmanangercommon need to rely on this project, and this project also relies on some third-party packages.

Let's describe how these sections are configured in JBoss EAP 6.2:
Logmanagercommon and Commonclass are used for Lib created by the user and need to be configured as JBoss module.

Commonclass was beaten into a jar package, placed in Jboss-eap-6.1\modules\com\xx\ngoss\xxx\commonclass\main, and configured Module.xml file as follows,

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" ><?xml version= "1.0" encoding= "UTF-8"? ><module xmlns= "urn:jboss:module:1.1" Name= " Com.xx.ngoss.xxx.commonClass ">  <dependencies>    <module name=" Javax.api "/>    <module Name= "Javax.transaction.api"/>    <module name= "org.jboss.remote-naming"/> <module name=    " Org.jython "/>  </dependencies>  <resources>    <resource-root path=" Commonclass.jar "/ >  </resources></module></span></span>

Where the name attribute in the <module> tag names the module Com.xx.ngoss.xxx.commonClass, while the <dependencies> The tag identifies the other modules that the Commonclass module relies on:

• Commonclass relies on the Javax.api module in the JBoss container, a set of javax packages related to the naming service, in the system module jboss-eap-6.1\modules\system\layers\base\javax\api\ The JAVAX.API module is configured in Main.
• The Commonclass relies on the Javax.transaction.api module in the JBoss container, which corresponds to the jboss-transaction-api_1.1_ Spec-1.0.1.final-redhat-2.jar a jar package located in the Jboss-eap-6.1\modules\system\layers\base\javax\transaction\api\main directory, By default, the container is configured as a JAVAX.TRANSACTION.API module.
• The Commonclass relies on the org.jboss.remote-naming module in the JBoss container, corresponding to the Jboss-remote-naming-1.0.6.final-redhat-2.jar located \ A jar package in the Jboss-eap-6.1\modules\system\layers\base\org\jboss\remote-naming\main directory, By default, the container is configured as a org.jboss.remote-naming module.
• Commonclass also relies on a third-party package Jython.jar, which needs to be introduced and configured as a new JBoss module. We put it under the Jboss-eap-6.1\modules\org\jython\main, the corresponding module.xml in the configuration module name is Org.jython.

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" ><?xml version= "1.0" encoding= "UTF-8"? ><module xmlns= "urn:jboss:module:1.1" name= "Org.jython" >    <dependencies>        <module name= "Javax.api"/>    </dependencies><resources>< Resource-root path= "Jython.jar"/></resources></module></span></span>

Logmanger is where the EJB business is implemented, and the final deployment is placed in the jboss-eap-6.1\standalone\deployments. Unlike the previous JBoss as, the dependency of an EJB project in JBoss EAP 6.1 (AS7) on the JBoss module needs to be indicated in the MANIFAST.MF file. Logmanager/src/meta-inf/manifest. MF files are configured as follows:

This indicates that the EJB project has an effect on the JBoss EAP 6.1 of the configured modules Com.xx.ngoss.xxx.commonclass,com.xx.ngoss.xxx.logmanagercommon and Org.jboss.log4j.logmanager dependencies. To complete the configuration of the entire EJB in JBoss. Stripping business implementation, the configuration of this log component consists of the following three steps:

• To configure a third-party package as a module
• Configure the package you build as a module, set up the system module on which the module depends, or a third-party package module
• Specifying the dependencies of the project on the JBoss module in the MANIFEST.MF of EJB project

The system comes with a package, a third-party package, a custom package becomes a module, a dependency is specified between the module and the build, and the EJB project needs to indicate that the dependencies are related to the components in the JBoss EAP. The concept of components in JBOSS EAP 6.1 is deep into the bone marrow.

Summary

This article first introduces the simplest implementation of EJB 3.1, and then introduces an instance class that shows how the JBoss module is configured to the EJB project, the user-created Lib, the third-party LIB, and the system Lib to clearly indicate the dependency relationship. This design provides the possibility for JBoss container optimization. It is also fully proven in the startup and restart speed of JBoss EAP 6.1.

However, from the developer's point of view, although the development environment of JBOSS landing performance has been greatly improved, but this all Lib need to be configured as module mode is not originally directly into the way of the Lib is easy to implement, because the module may be configured in the $jboss_eap$/ Modules directory under any level of directory, some may be inside the system has already, some need to introduce, where to introduce, all by the developer's discretion. This freedom gives developers extra work on the one hand, and if multiple developers develop together, different modules introduce the same package to different levels of the directory, causing conflicts.

Summarize

In summary, the module declaration of the new characteristics of the container, from a performance point of view is worth appreciating, but for the developers are mixed advantages and disadvantages, we slowly in-depth experience it.

JBOSS EAP 6 Series four EJB Implementation-invoke (module through always)