Deploying your first application to WildFly 8_Java EE 7 Development with WildFly-QQ阅读都市男生网

书名：Java EE 7 Development with WildFly
作者名：Micha? ?mil Micha? Mat?oka Francesco Marchioni
本章字数：1914字
更新时间：2025-02-24 05:34:40

Deploying your first application to WildFly 8

In order to test launch our first application, we will create a HelloWorld web project using Eclipse. The main part will be a servlet class, used to generate HTML markup. So, launch Eclipse and choose to create a new web project by navigating to File | New | Dynamic Web Project. This is shown in the following screenshot:

Choose a name for your application and check the Use default location box if you want to create your project within the same location of your Eclipse workspace. If you have correctly configured a new WildFly server in Eclipse, you should see the WildFly 8.0 Runtime option selected by default, and Target Runtime and Default Configuration for WildFly 8.0 Runtime preselected in the Configuration box.

Select 3.1 as the Dynamic web module version, which makes development easy by using the Servlet 3.1 specifications, and also leave the EAR membership and Add project to working sets checkboxes unselected.

Click on Finish to continue.

Now, let's add a quintessential simple servlet to our project, which merely dumps a Hello World message as an HTML page. From the File menu, go to New | Servlet and enter a meaningful name and package for your servlet, such as TestServlet as the name and com.packtpub.wflydevelopment.chapter2 as the package name. This is shown in the following screenshot:

The wizard will generate a basic servlet skeleton that needs to be enhanced with the following set of code lines:

@WebServlet("/test")
public class TestServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    private static final String CONTENT_TYPE = 
      "text/html;charset=UTF-8";
    private static final String MESSAGE = "<!DOCTYPE html><html>" +
            "<head><title>Hello!</title></head>" +
            "<body>Hello World WildFly</body>" +
            "</html>";

    @Override
    protected void doGet(HttpServletRequest request, 
                         HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType(CONTENT_TYPE);
        try (PrintWriter out = response.getWriter()) {
            out.println(MESSAGE);
        }
    }
}

The servlet will respond with a static HTML page (we defined the content type as Text/HTML with an UTF-8 charset) for every GET HTTP request that will be issued against its URL address.

Note

Notice that TextServlet bears the @WebServlet annotation, which has been introduced by the Servlet 3.0 API, and it allows registering a servlet without using the web.xml configuration file. In our example, we used it to customize the servlet URL binding to employ /test, which would otherwise be defaulted by Eclipse to the class name.

We will complete the application with the creation of a JBoss file descriptor named jboss-web.xml in /WebContent/WEB-INF/ directory; although this is not mandatory, it can be used to redefine the context root, as shown in the following code snippet:

<jboss-web>
    <context-root>/hello</context-root>
</jboss-web>

Note

The schema definition file for jboss-web.xml is named jboss-web_8_0.xsd and can be located in the JBOSS_HOME/docs/schema folder.

Keep in mind that creating jboss-web.xml makes the application non-portable to other Java EE Application Servers. The default application path when such a file is not defined is a concatenation of the application name and its version, for example, for application TestServlet with Version 1.0, it would be TestServlet-1.0.

Now, we will add the web application to the list of deployed resources by right-clicking on the Eclipse Server tab and selecting Add and Remove. This is shown in the following screenshot:

Next, click on Add to add the project to the list of configured resources on the server as shown in the following screenshot:

If you have started WildFly from inside Eclipse, the resource will be automatically deployed by checking the flag to see whether the server has started, and publish changes immediately.

If, on the other hand, you have started the application server externally, then you can fully publish your resource by right-clicking on the application and selecting Full Publish as shown in the following screenshot:

Now, move to the browser and check that the application responds at the configured URL, as shown in the following screenshot:

This example is also available in the form of a Maven (will be introduced in the next chapter) project in your Packt Publishing account.

Advanced Eclipse deployment options

As it is, Eclipse has published a HelloWorld.war folder in JBOSS_HOME/standalone/deployments.

Note

You might have noticed that Eclipse has also added a marker file named HelloWorld.war.dodeploy. This step is necessary because, by default, exploded deployments in WildFly aren't automatically deployed. Autodeployment of the exploded content is disabled by default because the deployment scanner could try to deploy the copied directory partially, which would cause a lot of errors. The deployment of the exploded archives can be manually triggered with a marker file named application.[jar/war/ear].dodeploy.

Once the application is deployed, the application server replaces the .dodeploy marker file with HelloWorld.war deployed, or with a HelloWorld.war.failed file, should the deployment fail.

You can change the default deployment options by double-clicking on WildFly 8.0 (in the Server tab), and selecting the Deployment tab as shown in the following screenshot:

In the Deployment tab, you can choose to deploy your application on a custom deploy folder by checking the Use a custom deploy folder option and entering an appropriate value into the corresponding textbox.

Please note that the custom deployment folder also needs to be defined in WildFly; check the next section for more information about it.

Also, take note of the Deploy projects as compressed archives option, which can be useful in some circumstances, for example, if you are distributing the application via other instruments such as the CLI, which can deploy only compressed archives.

Managing deployments with the web console

Deploying the application using Eclipse is a straightforward task and is likely to be your option when you are developing apps. We will see here how to use the web console to deploy the application, which can be one more arrow in your quiver.

Note

A typical scenario for this example could be if you are running the AS in the domain mode, or simply deploying your application on a remote WildFly instance.

Start the web console and click on the Runtime tab. From the panel on the left, go to Server | Manage Deployments as shown in the following screenshot:

Managing deployments with the web console

In the central panel, we can manage deployments using the Add, Remove, En/Disable, and Update buttons. Select the Add button to add a new deployment unit. In the next screen, pick up the file you want to deploy (for example, the HelloWorld.war artifact, which can be created from our test project in Eclipse by navigating to File | Export | Web | WAR File) from your local filesystem, as shown in the following screenshot:

Complete the wizard by verifying the deployment's name and clicking on Save, as shown in the following screenshot:

Now, the deployment is listed in the Deployments table. It is, however, not enabled by default. Click on the En/Disable button to enable the deployment of the application, as shown in the following screenshot:

Changing the deployment scanner properties

As we have seen before, applications running in the standalone mode are scanned in the deployments folder by default. You can change this behavior (and also the deployment scanner's properties) by clicking on the Configuration tab and navigating to Subsystems | Core | Deployment Scanners from the left menu. This is shown in the following screenshot:

In Deployment Scanners, you can set the core deployment's attributes. You can click on the Edit button to define new values for these properties. Most of them are self-explanatory; however, the following table summarizes them:

Deploying applications using the command-line interface

Another way to deploy an application is via the WildFly Command-line Interface (CLI), which can be started from jboss-cli.bat (or jboss-cli.sh for Linux users). Don't be afraid of using a textual interface to manage your application server; as a matter of fact, the console provides built-in autocomplete features and you can display the available commands at any time by simply hitting the Tab key, as shown in the following screenshot:

As you might have guessed, in order to deploy an application, you need to issue the deploy shell command. When used without arguments, the deploy shell command provides a list of applications that are currently deployed. Refer to the following code:

[standalone@localhost:9990 /] deploy
ExampleApp.war

If you feed a resource archive such as .war to shell, it will deploy it on the standalone server right away, as shown in the following command line:

[standalone@localhost:9990 /] deploy ../HelloWorld.war

As you can see from the preceding command line, the CLI uses the folder where your deployments were actually launched at its initial location, which is JBOSS_HOME/bin by default. You can, however, use absolute paths when specifying the location of your archives; the CLI expansion facility (using the Tab key) makes this option fairly simple. This is demonstrated in the following command line:

[standalone@localhost:9990 /] deploy c:\deployments\HelloWorld.war

There is no error message after issuing the command; therefore, the application is deployed and activated so that the user can access it. If you want to just perform the deployment of the application and defer the activation to a later time, you have to add the --disabled switch, as shown in the following command line:

[standalone@localhost:9990 /] deploy ../HelloWorld.war --disabled

In order to activate the application, simply issue another deploy shell command without the --disabled switch, as shown in the following command line:

[standalone@localhost:9990 /] deploy -–name=HelloWorld.war

Redeploying the application requires an additional flag for the deploy shell command. Use the -f argument to force the application's redeployment, as shown in the following command line:

[localhost:9990 /] deploy -f ../HelloWorld.war

Undeploying the application can be done with the undeploy command, which takes the application that is deployed as an argument. This is shown in the following command line:

[localhost:9990 /] undeploy HelloWorld.war

Deploying applications to a domain

Deploying applications when running in the domain mode is slightly different from doing this in the standalone mode. The difference boils down to the fact that an application can be deployed just to one server group or to all the server groups. As a matter of fact, one reason why you might split your domain into different server groups might be that you are planning to offer different types of services (and hence applications) to each server group.

So, in order to deploy your HelloWorld.war application to all server groups, issue the following command:

[domain@localhost:9990 /] deploy HelloWorld.war --all-server-groups

If, on the other hand, you want to undeploy an application from all server groups belonging to a domain, you have to issue the undeploy command, as shown in the following command line:

[domain@localhost:9990 /] undeploy HelloWorld.war --all-relevant-server-groups

You can also deploy your application just to one server group of your domain by specifying one or more server groups (separated by a comma) with the --server-groups parameter, as shown in the following command line:

[domain@localhost:9990 /] deploy HelloWorld.war --server-groups=main-server-group

You can use the tab completion facility in order to complete the value for the list of --server groups elected for deployment.

Now, suppose we wish to undeploy the application from just one server group. There can be two possible scenarios. If the application is available just on that server group, you will just need to feed the server group to the --server-groups flag, as shown in the following command line:

[domain@localhost:9990 /] undeploy HelloWorld.war --server-groups=main-server-group

On the other hand, if your application is available on other server groups as well, you need to provide the additional --keep-content flag; otherwise, the CLI will complain that it cannot delete an application that is referenced by other server groups, as shown in the following command line:

[domain@localhost:9990 /] undeploy HelloWorld.war --server-groups=main-server-group --keep-content