Deploying the web application - JBoss

Deploying the web application

Once you are happy with your settings, you can deploy and verify your application. If you are deploying your application from within Eclipse, just right-click on the JBoss Runtime Server and choose the Add and Remove option. Next, add the web project to the list of deployed projects. You can actually deploy the application by right-clicking on the project and choosing Full Publish.

You will notice that once your application is deployed, Eclipse will move on the server the web application archive (as7project.war) along with a file named as7project.war.dodeploy.

If you want to build your career as a JBoss professional, then visit Mindmajix - A Global online training platform for the “JBoss Training”  Course.  This course will help you to achieve excellence in this domain.

As you will learn in Chapter 6, Deploying Applications on JBoss AS 7, expanded archives, by default, require a marker file in JBoss AS 7 to trigger the deployment. Luckily, Eclipse is aware of it and does its job well.

Upon successful deployment, the as7project.war.dodeploy will be replaced by an as7project.war.deployed marker file, which indicates that you have successfully deployed the web application. You can verify that your application works correctly by pointing to the home.xhtml

page:  https://localhost:8080/as7project/home.xhtml.

Deploying a web application to the root context

In this example, we have shown how to deploy the web application to a custom context using the JBoss-web.xml. One particular case of Web context is the root

context, which will be used by the Web server if you don’t provide a specific one in your request. This typically resolves to https://localhost:8080 and is used to provide some welcome context by the Web server. By default, JBoss AS 7 has a root context that is mapped in the JBOSS_HOME/welcome-content folder. You can, however, override it by deploying one of your applications to the root context. This requires two simple steps:

Adding a remote EJB client

A couple of weeks before this book was printed, the new release 7.1.0 Beta of the application server was finally available for download. This release adds some enhancements, the most important one being the introduction of a new JBoss specific EJB client API, which can be used to perform remote invocations on the EJBs.

In order to test our application with a remote client, we need at first to provide a remote interface to the EJB:

The concrete implementation of this interface is the SingletonBeanRemoteImpl class, which has the same java method implementations as the SingletonBean class that we have shown in the earlier section:

?Here comes the most interesting part, which is the remote EJB client. EJB remote invocation happens through the Remoting framework, which uses Simple Authentication and Security Layer (SASL) for client-server authentication. In the current release of the application server, we need to explicitly set the Security provider, by adding into our test client the following specification:

This will grant anonymous access to the remote server where EJBs located. The next tricky part is determining the JNDI name of the EJB, which needs to be looked up.

The actual JNDI name of the EJB varies, depending on the type of EJB. The following table reinforces the two available syntax for both SLSBs and SFSBs:

That’s a pretty complex syntax. However, we will try to dissect every piece of it with another reference table:

Now you should be pretty comfortable with the tedious JNDI namespacing and ready to understand the client code:

Frequently asked Jboss Interview Questions

Learn JBoss Tutorial

As you can see, the major complexity of the remote EJB client code is related to the JNDI lookup section. You might have noticed that in the highlighted section, we have initialized the JNDI Context with a property named Context.URL_PKG_PREFIXES to specify the list of packages prefixes to be used when loading URL context factories. In our case, we have set it to org.jboss.ejb.client.naming so that the JNDI API knows which classes are in charge to handle the ejb: namespace.

Finally, you might wonder how the client actually knows the server location where the remote EJB is hosted. This will be solved by the following client-side property file named JBoss-ejb-client.properties that needs to be available to the client classpath:

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost remote.connection.default.port = 4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

Within this file, you can specify a set of properties prefixed by remote.connectionprovider.create.options, which will be used during the remote connection. In our example, we have just set the org.xnio.Options.SSL_ENABLED to false, which means that a clear text transmission will be used to connect the client and the server.

The remote.connections is used to specify a set of one or more connections that map to an EJB receiver. In our case, there is a single remote connection named default, which maps to the host localhost and the remoting port 4447.

Finally, we need to specify that a SASL anonymous connection will be used, otherwise, without authentication, our connection will be refused.