Java EE 7 Development with WildFly

Java EE 7 includes a new version of the JSF specification, which is not so revolutionary as 2.0, but still provides some appealing additions for developers. The key features delivered by JSF 2.2 are as follows:

Compared to EJB 3.1, the Version 3.2 is a minor update of the existing version. It concentrates mainly on marking some older features as obsolete (they are now optional, which means that not every Java EE 7-compliant application server will support them). The optional features are connected with persistence to web services based on EJB 2.1 and JAX-RPC. The main enhancements provided by the new specification are as follows:

Transactional parts of the EJB specification have been extracted and reused in other parts of the Java EE platform (the transaction support has been placed in the JTA 1.2 specification). For instance, the transactional behavior can now be used in CDI beans, thanks to the introduction of the @Transactional annotation.

JPA was introduced as a standard part of Java EE in Version 5 of the specification. JPA was intended to replace entity beans as the default object-relational mapping framework for Java EE. JPA adopted ideas from third-party object-relational frameworks, such as Hibernate and JDO, and made them a part of the standard version.

JPA 2.1 is an improvement over JPA 2.0 as it provides several facilities for developers, which are as follows:

Additionally, Java EE 7-compliant containers must now support preconfigured data sources (along with other resources), which can be instantly used by JPA entities.

WildFly uses Hibernate as its JPA provider and is shipped with a ready-to-use H2 in-memory database. The default data source points to the H2 instance hosted inside of the application server.

Version 1.1 of Contexts and Dependency Injection (CDI) provides improvements for the issues identified in CDI after its introduction in Java EE 6. The process of simplifying the programming model started in Version 1.0 and is now being continued. The areas covered by the update are as follows:

Weld is the CDI implementation internally used in WildFly.

The new version of the Java Servlet API has a clear focus on new features. The most important of them is the HTTP upgrade mechanism, which allows the client and server to start a conversation in HTTP 1.1, and negotiate another protocol for subsequent requests. This feature was used to implement the WebSockets mechanism in Java EE 7. Other features of the new version of specification are as follows:

In Java EE 7, the JAX-RS specification has been enriched with some long-awaited features. The version has changed from 1.1 to 2.0 because of the major impact of the improvements that came with the new specification. The most important features are listed as follows:

WildFly comes bundled with RESTEasy, an implementation of JAX-RS 2.0.

The JSR 343 is the first update for the JMS specification in over a decade. Once more, the main theme of the update is the simplification of the API. The new API dramatically decreases the amount of boilerplate code that has to be written by the programmer while still maintaining backwards compatibility. Other new features are listed as follows:

HornetQ is the JMS provider used and developed by JBoss. It is possible to use it outside of WildFly as a standalone message broker.

The process of updating the Bean Validation in Java EE 7 concentrates on two main features:

Concurrency utilities is a new feature pack to use multithreading in Java EE application components. The new specification provides ManagedExecutorService (a container-aware version of ExecutorService known from Java SE), which can be used to delegate the execution of tasks to a separate thread. These managed tasks could use most of the features that are available for application components (such as EJBs or Servlets). It is also possible to schedule cyclic or delayed tasks using new ManagedScheduledExecutorService. These new additions to the platform are filling a functional gap for Java EE, which was very hard to overcome within its architecture earlier on.

Batch jobs were another area of enterprise application development, which was not covered by earlier versions of Java EE. The new batch processing framework is used to provide a common solution to run tasks that are executed without user interaction. Java EE provides the developer with the following options:

Java EE 7 now comes with out-of-the-box JSON processing, so the developer is no longer forced to use external libraries for this task. The new API allows JSON processing to use two approaches: object model (DOM based) and streaming (event-based).

To fully support the development of applications based on HTML5, Java EE 7 requires a standardized technology for two-way communication between the server and the user's browser. The WebSocket API allows the developer to define server-side endpoints, which will maintain a TCP connection for every client that will connect to them (using, for instance, a JavaScript API). Before the new specification, developers had to use vendor-specific libraries and not portable solutions to achieve the same goal.

Once you have completed your installation, run the java -version command from a command prompt to verify that it is correctly installed. Here is the expected output from a Windows machine:

C:\>java –version
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)

The JBoss WildFly application server can be downloaded for free from http://wildfly.org/downloads/.

As you can see in the following screenshot, at the moment of writing this book, the latest stable release of WildFly is 8.1.0.Final, which features a Certified Java EE 7 full profile:

Once you have chosen the appropriate server distribution, you will then be warned that this download is part of a community release and, as such, is not supported.

Installing WildFly is a piece of cake; it does not require anything else besides unpacking the wildfly-8.1.0.Final.zip archive.

Windows users can simply use any uncompressing utility, such as built-in compressed folders (in newer Windows releases), WinZip, WinRAR, or 7-Zip taking care to choose a folder name that does not contain empty spaces and white spaces. Unix/Linux should use the $ unzip wildfly-8.1.0.Final.zip unzip shell command to explode the archive.

After you have installed WildFly, it is wise to perform a simple start up test to validate that there are no major problems with your Java VM / operating system combination. To test your installation, move to the bin directory of your JBOSS_HOME (the path to which you have unzipped your application server) directory and issue the following command:

standalone.bat    # Windows users
$ ./standalone.sh   # Linux/Unix users

The following is a screenshot of a sample WildFly start-up console:

The preceding command starts up a WildFly standalone instance, which is equivalent to starting the application server with the run.bat/run.sh script used by earlier JBoss AS releases. You will notice how amazingly fast the new release of the application server is; this is due to the modular architecture introduced in Version 7 of JBoss AS, which only starts up necessary parts of the application server container needed by the loaded applications.

If you need to customize the start-up properties of your application server, open the standalone.conf file (or standalone.conf.bat for Windows users), where the memory requirements of Wildfly have been declared. Here is the Linux core section of this file:

if [ "x$JAVA_OPTS" = "x" ]; then
    JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m
       -Djava.net.preferIPv4Stack=true"
    JAVA_OPTS="$JAVA_OPTS
        -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS
        -Djava.awt.headless=true"
else
    echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"

So, by default, the application server starts with a minimum memory requirement of 64 MB of heap space and a maximum of 512 MB. This will be just enough to get started; however, if you need to run more robust Java EE applications on it, you will likely require at least 1 GB of heap space or 2 GB or more, depending on your application type. Generally speaking, 32-bit machines cannot execute a process whose space exceeds 2 GB; however, on 64-bit machines, there is essentially no limit to the process size.

You can verify that the server is reachable from the network by simply pointing your browser to the application server's welcome page, which can be accessed from the well-known address, http://localhost:8080. The welcome page of WildFly is shown in the following screenshot:

If you have been using previous releases of the application server, you might have heard about the twiddle command-line utility that queried MBeans installed on the application server. This utility has been replaced by a more sophisticated interface named the command-line interface (CLI); it can be found in JBOSS_HOME/bin.

Just launch the jboss-cli.bat script (or jboss-cli.sh for Linux users), and you will be able to manage the application server via a shell interface. This is shown in the following screenshot:

We started an interactive shell session that can also use the command-line completion (by pressing the Tab key) to match partly typed command names. No more searches are needed to find the exact syntax of commands!

The command-line interface is discussed in depth in Chapter 9, Managing the Application Server, which is all about server management interfaces; we will, however, get an initial taste of its basic functionalities in the next sections to get you accustomed to this powerful tool.

The easiest way to stop WildFly is by sending an interrupt signal with Ctrl + C.

However, if your WildFly process was launched in the background or, rather, is running on another machine, you can use the CLI interface to issue an immediate shutdown command:

[disconnected /] connect
Connected to localhost:9990
[standalone@localhost:9990 /] :shutdown

jboss-cli.bat --connect command=:shutdown      # Windows
./jboss-cli.sh --connect command=:shutdown       # Unix / Linux

[disconnected /] connect 192.168.1.10
Authenticating against security realm: ManagementRealm
Username: admin1234
Password:
Connected to 192.168.1.10:9990
[standalone@192.168.1.10:9990 / ] :shutdown

The command-line interface contains many useful commands. One of the most interesting options is the ability to reload the AS configuration or parts of it using the reload command.

When issued on the root node path of the AS server, the reload command can reload the services' configuration:

[disconnected /] connect
Connected to localhost:9990
[standalone@localhost:9990 /] :reload

The next step will be installing the JBoss AS plugin that is a part of the suite of plugins named JBoss Tools. Installing new plugins in Eclipse is pretty simple; just follow these steps:

Completing the server installation in Eclipse is quite straightforward as it just requires pointing to the folder where your server distribution is; we will therefore leave this to you to implement as a practical exercise.

Once you have completed your installation, run the mvn version to verify that Maven has been correctly installed. Refer to the following code snippet to verify the correct installation:

> mvn –version
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
Maven home: C:\Programs\Dev\apache-maven-3.1.1
Java version: 1.8.0_11, vendor: Oracle Corporation
Java home: C:\Programs\Java\jdk1.8.0\jre
Default locale: en_US, platform encoding: Cp1250
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"