In this chapter, we will cover the following recipes:
f Adding WildFly support to NetBeans
f Adding TomEE support to NetBeans
f Creating a web application
f Creating a web application with JSF support
f Adding JSF support to a web application
f Creating a JSF composite component
f Creating an EJB
f Creating a Message Driven EJB
f Creating a timer
f Creating a REST web service
f Using the Chrome Connector
Introduction
Java EE is a remarkable technology for all that it can accomplish, but in earlier versions, it was criticized for being overly complicated and verbose.
Much of this criticism was justified for the fact that Java EE relied heavily on XML-based configuration, requiring many interfaces and exceptions, and presenting developers with many hurdles to face when using it. Technologies such as Hibernate and Spring emerged, and gained much attraction simply because they sought to address those complexities.
With the introduction of Java EE 5, the core platform once again gained the upper hand, tying together the same formula that helped catapult Hibernate and Spring into developers' favor.
Annotations were brought in to tone down the verbosity of code, along with the reduction of checked exceptions, POJO programming, introduction of JSF, enhancements in EJB QL and Application Container, and simplification of Session Beans.
Session Beans are Java objects that perform a multitude of operations but are mainly used for managing transactional data. With Java EE 7, Session Beans can be either Stateless, Stateful, or Singleton beans:
f Stateful Session Beans maintain a conversational state for the entire client session.
f Stateless Session Beans do not maintain a conversational state. These beans are maintained in memory for as long as the client request takes and after that, the state is no longer kept in memory.
f Singleton Session Beans are guaranteed to only have one instance within an application and exist for the entire life of the application.
The idea of simplifying development continues in Java EE 7. Java EE 7 has three main aims, as follows:
f Increase developer productivity by requiring less boilerplate code and using more annotations / less XML
f Provide better HTML 5 support with the likes of JSON processing, REST and Web Sockets
f Meet enterprise demands with the new batch, concurrency and simplified JMS APIs In Java EE 7, some of the heavyweight, outdated technologies and APIs such as JAXR, EJB 2.x Entity Beans, and Java EE Application Deployment, have been marked as pruned, either for low usage by developers, or for not being entirely implemented by the vendors that chose to create the application containers. On top of that, performance enhancements for deployment and resources used, such as Java EE web profiles, were added so that developers who do not utilize the entire Java EE stack can deploy applications based only on what they use, enabling a much more lightweight application.
Adding WildFly support to NetBeans
Many years ago, JBoss released its first application server, the JBoss application server. The JBoss application server was developed as an open source software up until version 7, when it was redeveloped and renamed WildFly 8. WildFly 8 is one of the most used open source Java EE application servers available. Version 8 fully supports both the Java EE 7 full and web profiles making it one of the select few application servers that fully supports the Java EE 7 full platform.
WildFly is built on top of many open source projects such as Hibernate for persistence, Weld for contexts and dependency injection, and Mojarra for Java Server Faces.
WildFly provides both web-based and command-line-based management tools together with full Maven support for managing project deployments. These tools allow NetBeans to provide full control over WildFly when developing Java EE applications.
A standalone and a domain mode of WildFly are provided with the distribution. The standalone mode is most likely what developers will use during application development as it provides a single application server instance running within a single JVM. The domain mode allows WildFly to run across multiple JVMs while providing synchronization of applications and settings across different JVMs. In this recipe, we'll discuss the standalone mode of WildFly.
Before we see how to install WildFly support within NetBeans, let's first take a look at how to install WildFly and take a quick look around WildFly's application structure.
Installing WildFly is a very straightforward process. Simply download the distribution from the project's download site (http://wildfly.org/downloads) and unzip/untar it into a local directory.
For each release of WildFly, the full EE 7-certified application server, a minimalistic core distribution and the application server source code can be downloaded. Ensure that you download the full Java EE 7-certified server:
WildFly is provided under the LGPL v2.1 license, so please ensure that you have read the license (http://www.gnu.org/licenses/lgpl-2.1.html) before using the software.
Once unzipped/untarred, the WildFly directory structure will look like the following screenshot:
Let's take a look at what these different directories mean in WildFly:
Directory Description
appclient Configuration files used by the application client container bin Management scripts including those to start up the
application server
docs Example configuration files together with XML schema definitions
domain Configuration files and deployments for the domain mode configuration
modules Modules (additional .jar files) required by the application server, for example, database drivers or JSON providers standalone Configuration files and deployments for the standalone
mode configuration
welcome-content Contents for the default homepage for the application server
Once you've installed WildFly, you need to learn how to start the application server. To start WildFly, open a command prompt (or a terminal if running on Linux/Mac OS X), change the directory to the root installation of WildFly, and execute one of the following commands:
f If running on Windows, use this command: bin\standalone.bat
f If running on Linux/Mac OS X, use this command: ./bin/standalone.sh The following screenshot shows WildFly starting up in a Windows command shell:
To stop WildFly, press Ctrl + C within the command/terminal window. Now that we've had a brief overview of WildFly, let's see how to integrate it into NetBeans.
Getting ready
To add WildFly as an application server within NetBeans, it's preferable to be running the Java EE download bundle of NetBeans so that additional plugins other than WildFly do not need to be installed.
It's recommended to use the latest version of either Java 7 or Java 8 for both NetBeans and WildFly, so if you haven't got one of those installed yet, you can install either of them from http://www.oracle.com/technetwork/java/index.html
How to do it …
Perform the following steps:
1. Ensure that NetBeans is running, and then click on Tools and then Plugins from the main menu.
2. Click on the Available Plugins tab. Notice that the number in brackets at the end of the tab name shows the number of available plugins as shown in the following screenshot:
3. Locate the WildFly Application Server plugin and check the Install checkbox next to it.
4. Click on the Install button.
5. The NetBeans IDE plugin installer will now be displayed showing that the WildFly application server plugin is to be installed.
6. Click on Next, accept the license agreement, and then click on Install.
7. When prompted, select Restart the IDE Now to complete the installation of the plugin.
NetBeans will now restart with the WildFly plugin successfully installed. The final stage is to add a WildFly server instance into NetBeans so that we can start developing applications against it. Perform the following steps:
1. Click on Tools and then click on Servers from the main menu. The NetBeans Servers definition dialog will now be displayed:
2. Click on the Add Server button.
3. On the Add Server Instance dialog, select WildFly Application Server as shown in the following screenshot:
4. Click on Next.
5. Enter the Server Location field as the home directory where you previously installed WildFly.
I always install my development software into a c:\DevTools folder, so for me, the Server Location field would be set to c:\DevTools\WildFly-8.0.0.Final.
6. Upon specifying Server Location, the Server Configuration field will be automatically set to the configuration file of the standalone WildFly instance within your distribution.
7. Click on Next.
8. The Instance Properties page will now be shown. Verify that the default Host value is localhost and Port is 8080, and change them to the values for your environment if not.
9. Click on Finish.
10. You have now added an instance of the WildFly application server within NetBeans.
Click on Close to exit the Servers dialog.
How it works…
We've now successfully added an instance of WildFly into NetBeans, but how do we control the server? If we locate the Services explorer, the Servers node displays a list of all application servers registered within NetBeans including our newly registered WildFly instance. Right-clicking on the server displays a context menu that allows the server to be started (in standard, debug or profiling modes), stopped, or restarted. We can view the server log, which displays the running WildFly console output into the NetBeans Output window.
This can be especially useful for examining debug messages and WildFly log messages while debugging applications.
Located within the WildFly application server node on the Services explorer, we can also see what Enterprise Applications, EJBs, and web modules are deployed. From here, we can also stop and undeploy them.
We can also see what resources are deployed to the application server, whether they are data sources, JMS resources, or mail sessions. The current version of the NetBeans plugin allows us to view these resources, but not edit them.
Viewing the application server properties allows us to specify the configuration file that defines the application server instance (although, you'll probably never need to change that). We can also change the VM options that are used to start the application server. The default JVM settings (-Xms128m -Xmx512m -XX:MaxPermSize=256m) are probably sufficient for most small applications, but may need modifying for larger applications. JVM settings such as these will only take effect upon restarting the server.