Oracle Blog

Arun Gupta's Weblog

Monday Nov 26, 2012

EJB 3.1 added a whole ton of features for simplicity and ease-of-use
such as @Singleton, @Asynchronous, @Schedule, Portable JNDI name,
EJBContainer.createEJBContainer, EJB 3.1 Lite, and many others. As
part of Java EE 7, EJB 3.2 (JSR 345) is making
progress and this blog will provide highlights from the work done so
far. This release has been particularly kept small but include
several minor improvements and tweaks for usability.

More features in EJB.Lite

Asynchronous session bean

Non-persistent EJB Timer service

This also means these features can be used in embeddable EJB
container and there by improving testability of your
application.

Pruning - The following features were made Proposed Optional
in Java EE 6 and are now made optional.

EJB 2.1 and earlier Entity Bean Component Contract for CMP
and BMP

Client View of an EJB 2.1 and earlier Entity Bean

EJB QL: Query Language for CMP Query Methods

JAX-RPC-based Web Service Endpoints and Client View

The optional features are moved to a separate document and as
a result EJB specification is now split into Core and Optional
documents. This allows the specification to be more readable
and better organized.

The specification is still evolving so the actual property or
method names or their actual behavior may be different from the
currently proposed ones.

Are there any improvements that you'd like to see in EJB 3.2 ?
The EJB 3.2 Expert Group would love to hear
your feedback. An Early
Draft of the specification is available. The latest version
of the specification can always be downloaded from here.

Wednesday Apr 13, 2011

Sebastian Meyen, the chair of worldwide JAX Conference kick started JAX London 2011 with a very passionate opening session highlighting that JAX is all about Java, that they are comitted to Java, and not going to dilute the content. This is the 10th year of JAX conferences. Even though originally the word JAX was coined as an acronym for "Java Apache XML" indicating the open source nature and everything XML around Java but now its more popularly known as JAX.

The successful recipe for the JAX conference is "passion for the Java platform & ecosystem" and "a pramatic mix with development, architecture, agile, and other concepts around Java". In Sebastien's words "Java is a huge stake, heavily growing, innovating and worth focusing on it" and is a "rich environment for innovation". The JAX Innovation Awards giving $10,000 for the most innovative contributions to Java further proves their commitment to Java. Do you have the most innovative Java technology, most innovative Java company, and the top Java ambassador to recommend ? Submit now!

The first keynote of the day was by Dan North on the "Patterns of Effective Delivery". He highlighted several design patterns and the key ones were:

Spike and Stabilise - "Spike" is the non-TDD code written during the development cycle and then TDD applied to stabilise it for production.

Create Urgency - Create lots of instances where you are surprised, optimize for deliberate learning than for deliberate practice. Create an urgency for yourself for technologies that are genuinely useful. Difficult to change your thinking consciously, need a crisis.

Socratic Testing - Using the process of automated tests to draw out knowledge about the code.

Fits In My Head - Keeping the design small enough such that the entire design fits in your head, then you can reason the whole thing.

Being the chair of Java EE track, I spent most of my day attending the sessions there. The first session by Ales Justin explained how to run a Java EE application on Google App Engine. His slides are available below:

Ales explained his experience of building a sample application using JPA2, JSF2, Bean Validation, delpoing on GAE. The slides very well capture the restrictions of the platform and how he worked around them. The GAE API was even abstracted such that a pure Java EE application can be written and thus be portable across multiple application servers.

David Blevins's session on Fun with EJB 3.1 and Open EJB was indeed a lot of fun. He provided a good history of how the EJB and OpenEJB have evolved over years. There were lots of code samples highlighting the ease-of-use improvements done in EJB 3.1such as @Stateless, @Schedule, @Asynchronous, @Singleton, Embeddable EJB API and many others. I particularly loved his statement:

People who complain about EJB are stuck in 2005 and believe ignorance is my pride. Its testable, light, and pretty great!

Seriously, if you complain about EJB being heavy, non-functional, incomplete, the following code fragment is all it takes to create an EJB:

@Stateless
public class MyEJB {
public String myMethod(...) { }
}

and that too packaged in a WAR file, no deployment descriptors or any special packaging. Do you still think its heavy weight ? Think again!

Doug Clarke talked about "Java Persistence API 2.0 with EclipseLink", Joseph Shum talked about "Integrating Enterprise Applications into Liferay Portal", and then Dan Allen talked about "Using CDI Extensions to make a better Java EE". Dan showed several examples of how CDI extensions can be authored easily to extend capabilites of the existing platform. Their slides will be available on jaxlondon.com.

And I also gave two presentations:

GlassFish 3.1 - Simplifying your Java EE 6 Development and Deployment

OSGi-enabled Java EE Applications using GlassFish (in the OSGi track)

The first talk explained how several features in GlassFish 3.1 such as:

Deploy-on-Save (in NetBeans and Eclipse)

Active Redeploy (preserve sessions across re-deploys at CLI or NetBeans and Eclipse)

29% better startup/deploy/redeploy cycle

Application runner (java -jar glassfish.jar foo.war)

Maven integration (mvn gf:run, gf:start, gf:deploy, etc)

Embedded GlassFish

and many other features make GlassFish an extremely productive development environment for your Java EE 6 applications. And then features like:

High Availability, Clustering

Centralized Administration

Application-scoped Resources

Application Versioning

33% better High Availability performance

Better scalability - upto 100 instances per domain

RESTful monitoring and management

make it an equally compelling deployment platform. The slides with all the details are available below:

The first few slides are OSGi introductory so jump ahead to slide #22 for all the interesting stuff. The screencast #38 showcase how to build an OSGi-enabled Java EE Applications using Eclipse and GlassFish and comes with the complete and detailed instructions. The screencast #32 shows the same using NetBeans.

The day ended with a 1.5 hrs interactive Java EE 6 hackathon and more details on that in a later blog.

Tuesday Oct 19, 2010

EJB 3.1 has greatly simplified the ability to schedule events according to a calendar-based schedule, at a specified time, after a specified elapsed duration, or at a specific recurring intervals.

There are multiple ways events can be scheduled:

Programmatically using Timer service

Automatic timers based upon the metadata specified using @Schedule

Deployment Descriptor

This Tip Of The Day (TOTD) will show code samples on how timer-based events can be created in EJBs.

Lets start with programmatic creation of timers first.

The Timer Service allows for programmatic creation and cancellation of timers. Programmatic timers can be created using createXXX methods on "TimerService". The method to be invoked at the scheduled time can be any of the flavors mentioned below:

EJB implementing "javax.ejb.TimedObject" interface that has a single method "public void ejbTimeout(Timer timer)". For example:

The "initTimer" method is a lifecycle callback method and cleans up any previously created timers and then create new timers that triggers every 10th and 45th second. The "ejbTimeout" method, implemented from "TimedObject" interface is invoked everytime the timeout occurs. The "timer" parameter in the "ejbTimeout" method can be used to cancel the timer, get information on when the next timeout will occur, get information about the timer and other relevant data.

Notice, there is a @Startup class-level annotation which ensures that bean is eagerly loaded, lifecycle callback methods invoked and thus timers are created before the bean is ready.

At most one method tagged with "@Timeout". Methods annotated with @Timeout must have one of the following signature:

void <METHOD>()

void <METHOD>(Timer timer)

The second method signature gives you the ability to cancel the timer and obtain metatdata about the timer. These methods may be public, private, protected, or package level access. For example:

EJB 3.1 container reads the @Schedule annotations and automatically create timers. Notice, there is no need for a @Startup annotation here as lifecycle callback methods are not required. Each re-deploy of application will automatically delete and re-create all the schedule-based timers ... really clean and simple! No messing around with deployment descriptors too :-)

Interval timers created using TimerService can be easily created by using "ScheduleExpression.start()" and "end()" methods. The single-action timer can be easily created by specifying fixed values for each field:

The "timer" object contains information about the timer that just expired. Note that "info" is passed to each @Schedule annotation and "timer.getInfo()" can be used in "printTime" method to find out which of the timers expired.

Timers can be created in stateless session beans, singleton session beans, MDBs but not for stateful session beans. This functionality may be added to a future version of the specification.

Timers are persistent by default, need to made non-persistent programmatically (TimerConfig.setPersistent(false)) or automatically (by adding persistent=false on @Schedule)

Schedule-based timers may be optionally associated with a timezone.

The user code has no control over the timers created using @Schedule and thus cannot be canceled after creation.

Timers are not for real time as the container interleaves the calls to a timeout callback method with the calls to the business methods and the lifecycle callback methods of the bean. So the timed out method may not be invoked exactly at the time specified at timer creation.

This blog is derived from the whiteboard discussion with Linda as captured below and numerous emails with Marina for helping me understand the concepts.

Ah, the joys of sitting a few feet away from most of the Java EE 6 spec leads :-)

Tuesday May 18, 2010

One of the new features introduced in Enterprise Java Beans 3.1 (JSR 318) is asynchronous invocation of a business method. This allows the control to return to the client before the container dispatches the instance to a bean. The asynchronous operations can return a "Future<V>" that allow the client to retrieve a result value, check for exceptions, or attempt to cancel any in-progress invocations.

The "@Asynchronous" annotation is used to mark a specific (method-level) or all (class-level) methods of the bean as asynchronous. Here is an example of a stateless session bean that is tagged as asynchronous at the class-level:

The method signature returns "Future<Integer>" and the return type is "AsyncResult(Integer)". The "AsyncResult" is a new class introduced in EJB 3.1 that wraps the result of an asynchronous method as a Future object. Under the covers, the value is retrieved and sent to the client. Adding any new methods to this class will automatically make them asynchronous as well.

The 2 second sleep simulates server side processing of the response which may involve querying the database or reading some information from the filesystem.

This EJB can be easily injected in a Servlet using the normal way:

@EJB SimpleAsyncEJB ejb;

This business method can be invoked in the "doGet" method of a Servlet as:

The control is returned to the client right after the the EJB business method is invoked and does not wait for the business method execution to finish. The methods on "Future" API are used to query if the result is available. The "Thread.sleep()" for 1 second simulate that client can continue working and possibly check for results at a regular interval. The "print" is a convenience method that prints the string to "response.getWriter" and flushes the output so that it can be instantly displayed instead of getting buffered. Invoking this "doGet" shows the following output:

1274142978365: Client is working ...
1274142979365: Response not ready yet ...
1274142979365: Client is working again ...
1274142980366: Response not ready yet ...
1274142980366: Client is still working ...
1274142981366: Response is now ready
1274142981366: The result is: 30

The client transaction context does not and security context do propagate from the client to the asynchronous business method.

Up until now, any kind of asynchrony in the EJB required to use the Message Driven Beans which in turn required some JMS setup. Introduction of this feature allows you to easily incorporate asynchrony in your EJB applications.

The specification is not entirely new as the concept is borrowed from the EJB 3.0 specification and abstracted at a higher level so that it can be more generically applied to a broader set of specifications in the platform. Interceptors do what they say - they intercept on invocations and lifecycle events on an associated target class. Basically, interceptor is a class whose methods are invoked when business methods on the target class are invoked and/or lifecycle events such as methods that create/destroy the bean occur. Interceptors are typically used to implement cross-cutting concerns like logging, auditing, and profiling.

The "@AroundInvoke" annotation (can be only one per interceptor) on a method in the interceptor class ensures that this method is invoked around the business method interception. This will be more clear after the program flow is explained later. Multiple interceptors can be chained and the flow/outcome may be diverted in any of them using "InvocationContext".

and then invoke the bean's method in "doGet" or "doPost" methods of the servlet as:

String result = bean.sayHello("Duke");

Notice that @Inject is used to inject the managed bean and bean discovery is enabled by adding an empty "beans.xml". This ensures that CDI inject works as expected and all the interceptors are invoked as well. Another alternative is to inject the bean using @Resource but "beans.xml" need to be removed in order for the interceptors to be invoked. So inject your bean using @Inject + "beans.xml" or @Resource. The recommended approach is to use @Inject + "beans.xml" as CDI might be used in other parts of your applications as well.

If 2 interceptors, each with a separate interceptor binding, managed bean class, and the servlet is included in a web application then the directory structure will look like:

If there are "System.out.println"s inserted at relevant positions in the interceptor and the Servlet code, then the code flow looks like:

Before Intercept
Before Intercept2
sayHello
After Intercept2
After Intercept
processRequest

"Before XXX" messages are printed by a method from the interceptors, in the order of chaining, before "context.proceed" is invoked in all the interceptors. "sayHello" method is invoked from the "doGet" or "doPost" method in the Servlet. "After XXX" messages are printed from the interceptors after "context.proceed" method is invoked, this time in the reverse order of chain. And finally "processRequest" method is invoked again from the "doGet" or "doPost" method in the Servlet.

The complete source code for the sample explained above can be downloaded here.

A short definition for a managed bean - its a POJO that is treated as managed component by the Java EE container.

There are several component specifications in the Java EE platform that annotates a POJO to achieve the desired functionality. For example, adding "@Stateful" annotation to a POJO makes it a stateful EJB. Similarly adding "@javax.faces.bean.ManagedBean" to a POJO makes it a JSF managed bean. Java EE 6 introduces a new specification - "Managed Beans 1.0" that provides a common foundation for the different kinds of component that exist in the Java EE platform. In addition, the specification also defines a small set of basic services:

Resource Injection

Lifecycle callbacks

Interceptors

The different component specifications can then add other characteristics to this managed bean. The specification even defines well known extension points to modify some aspects. For example CDI/JSR 299 relaxes the requirement to have a POJO with no-args constructor and allow constructor with more complex signatures. CDI also adds support for lifecycle scopes and events. Similarly EJB is a managed bean and adds support for transactions and other services.

A managed bean is created by adding "javax.annotation.ManagedBean" annotation as:

The standard annotations "javax.annotation.PostConstruct" and "javax.annotation.PreDestroy" from the JSR 250 can be applied to any methods in the managed bean to perform any resource initialization or clean up by the managed bean. A bean with lifecycle callbacks can look like:

Its important to provide a name to the managed bean, as there is no default name, for the JNDI reference to work. EJB and CDI specifications extend this rule and provide default naming rules.

Once the bean is injected then its business methods can be invoked directly.

As part of Java EE 6, all EJB and CDI beans are defined as managed beans and so:

@Stateless
public class FooBean {
. . .
}

and

@Named
public class BarBean {
. . .
}

are implicitly managed beans as well.

No other beans in the Java EE platform are currently implicitly defined as managed beans. However JAX-RS resources can also be defined as EJB and CDI beans in which case the JAX-RS resources will be implicit managed beans as well. A future version of different component specifications may discuss if it makes sense to align other Java EE POJO elements to align with Managed Beans specification.

Unlike traditional Java EE server-based execution, embeddable usage allows client code and its corresponding enterprise beans to run within the same JVM and class loader. This provides better support for testing, offline processing (e.g. batch), and the use of the EJB programming model in desktop applications.

Earlierblogs already described the steps in detail but I had to try this stuff myself :-) And moreover this Tip Of The Day (TOTD) shows, as always, complete detailed steps to get you going from scratch.

Lets see how such an embeddable EJB application can be easily created.

The portable JNDI name for the EJB is "java:global/classes/App" (convenience name for a bean with one view) and the fully-qualified notation is "java:global/classes/App!org.glassfish.embedded.samples.App". The convenience name is constructed in the "global" namespace + the unqualified name of the directory + bean name. The later is created by adding the fully-qualified name of the interface to the former.

The server shuts down after the tests are run, shows that 2 tests (one default + one newly added) ran, and both passed.

So no explicit GlassFish downloading and/or configuring, just deployed a simple EJB, and ran the tests - everything within one VM.

A future blog will show how to add other Java EE functionality to this app.

This application is purposely not generated as a web application (missing "-DarchetypeArtifactId=maven-archetype-webapp"). If you specify this property then it will generate "WEB-INF/web.xml" which we don't intend to use.

"maven-compiler-plugin" needs to be specified as the default source level for Maven compile plugin is JDK 1.3. It's been over 9 years JDK 1.3 was released, not even listed on Java SE standard downloads page, EOLed many years ago. Vote/Comment for the issue MCOMPILER-80 if you'd like this bug to be fixed.

Adding "failOnMissingWebXml" ensures that Maven packages the WAR file even though no "web.xml" is present.

The complete list of Maven coordinates for GlassFish are available here.

JSF 2 uses Facelets as viewing technology and so an ".xhtml" file is used for all the JSF tags. This page is intentionally kept simple and not using any templating, composition, or any other features of Facelets. This page renders an HTML form with two text boxes and a command button, binds the value of text box to the managed bean, and displays the page "show.xhtml" when the command button is clicked. The default JSF 2 navigation handler try to match a view on the disk ("show.xhtml" in this case) based upon the "action" attribute.

And now your application is accessible at "http://localhost:8080/simplewebapp-1.0-SNAPSHOT/index.jsp" and looks like:

Clicking on "here" looks like:

The JSF page is accessible at "http://localhost:8080/simplewebapp-1.0-SNAPSHOT/index.jsf" and looks like (after entering the values):

Notice that even though the page is named "index.xhtml", it's accessed as "index.jsf". This is because the JSF specification provides recommended mapping for FacesServlet to "\*.faces" and "/faces/\*". In addition, Mojarra (Reference Implementation of JSF2 in GlassFish) also adds a mapping to "\*.jsf". Any views using these URL pattersn are routed through FacesServlet. So alternative URLs for our page are "http://localhost:8080/simplewebapp-1.0-SNAPSHOT/index.faces" and "http://localhost:8080/simplewebapp-1.0-SNAPSHOT/faces/index.xhtml".

Thursday Oct 01, 2009

TOTD #106 explained how to install Oracle database 10g R2 on Mac OS X. TOTD #107 explained how to connect this Oracle database using NetBeans. This Tip Of The Day will explain how to use the sample HR database (that comes with Oracle database server) to write a simple Java EE 6 application.

This application will use Java Server Faces 2.0 for displaying the results, Enterprise Java Beans 3.1 + Java Persistence API 2.0 for middle tier, and Oracle database server + GlassFish v3 as the backend. The latest promoted build (65 of this writing) will not work because of the issue #9885 so this blog will use build 63 instead.

Several improvements have been made over NetBeans 6.8 M1 build and this blog is using the nightly build of 9/27. The environment used in this blog is:

"Employees.findAll" is a default NamedQuery generated by NetBeans and makes it easy to query the database. Several other queries are generated for each mapped JPA class, such as "Employees.findByEmployeeId" and "Employees.findByFirstName". Custom queries can also be created and specified on the POJO class.

The GlassFish team is trying to bridge the gap by adding new Java EE 6 wizards that allows you to create Servlet 3.0- (JSR 315) and EJB 3.1- (JSR 318) compliant artifacts. So for the first time, in Eclipse, a Java EE 6 application can be created using the GlassFish plugin for Eclipse (ver 1.0.32)! GlassFish v3 is the Java EE 6 in making and so Eclipse and GlassFish v3 together provides you a good environment for your Java EE 6 development.

This Tip Of The Day (TOTD) explains how to use those wizards using Eclipse 3.4.2. If you have an earlier version of plugin already installed then update it as described in TOTD #66. Make sure to use ver 1.0.33 (recently released) if you are using Eclipse 3.5.x. If you have an earlier version of GlassFish plugin installed, then you may have to start Eclipse with "-clean" flag, basically as "eclipse -clean", after updating the plugin. This will allow the environment to detect the new plugins.

Using Eclipse 3.4.2, install the latest GlassFish Eclipse plugin (ver 1.0.32 or higher) in "Eclipse IDE for Java EE developers" as explained in screencast #28. The correct version snapshot is shown below:

and click on "Finish". This shows the default page "http://localhost:8080/index.jsp". Change the URL to "http://localhost:8080/ee6/HelloServlet" to see the output as:

The "web.xml" and "sun-web.xml" can be conveniently deleted from "WebContent", "WEB-INF" and the deployed page will continue to function as expected because all the information is captured in annotations instead of the deployment descriptors.