Browse DevX
Sign up for e-mail newsletters from DevX


Java EE 5.0: Towards Ease of Development : Page 2

Any J2EE developer knows how hard enterprise Java can be. Find out how the set of new Java EE 5.0 features, such as Web services support, annotations, and enhanced CMP, can make it easier.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Injection of EJB Entries

With the current J2EE architecture, in order to expose any business method, you need to provide EJB wrappers for the home and remote interfaces. But with Java EE 5.0, you can annotate any field or method of an application component with the EJB annotation. The annotation itself represents a reference to an EJB session bean. The reference may be to a local or remote home interface of the session bean, or it may be to the business interface of an EJB3 bean.

For example, the following code uses annotations to make a PurchaseOrder class into an EJB:

@EJB private PurchaseOrder po; @EJB( name = "ejb/myEnterpriseApp", beanName = "po1", beanInterface ="PurchaseOrder.class", description =" The Purchase Order for my enterprise application" ) private PurchaseOrder po;

The enterprise bean will have the JNDI look up the name java:comp/env/ejb/po. As the target of the name is not specified anywhere, the container must resolve the target.

Cool, huh?! Now you can make any of your existing applications into a Java EE application just by injecting the EJB annotations into your existing business methods and deploying them in a Java EE 5.0-compliant container.

In cases of conflict when a deployment descriptor is provided along with annotations, the container ignores the annotations and uses the deployment descriptor entry. This feature allows current J2EE applications to be migrated "as-is" to Java EE 5.0-compliant containers.

Enhanced Deployment Descriptors: Injecting Environment Entries

Along with the <ejb-ref> tag in deployment descriptors, Java EE 5.0 provides a new tag to make business fields accessible from the application component's code: <env-entry>. Alternatively, you can use the @Resource annotation tag for the same purpose.

For example, the following code uses an annotation to limit the number of items in a purchase order to 10:

// can be configured from the deployer @Resource int numberOfItems; public void validatePO(PurchaseOrder po) throws NumberOfItemsException { if(po.getItemCount() > numberOfItems) throw new NumberOfItemsException("My PO cannot have more than 10 items"); }

The following code uses a deployment descriptor for the same purpose:

<env-entry> <description> Number of Items in my PO </description> <env-entry-name> numberOfItems </env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>10</env-entry-value> </env-entry> Looking up this value: Context initContext = new InitialContext(); Context myEnv = (Context) initContext.lookup("java:comp/env"); Integer NumOfItems = (Integer) myEnv.lookup("numberOfItems");

When environment entries are injected into the code using either annotations or the <env-entry> tag, it is the container's responsibility to provide the lookup for these values.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date