Deploying the web application

Recommended by 0 users

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. 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 a 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: http://localhost:8080/as7project/home.xhtml.


Deploying a web application to the root context

In this example, we have showed 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 http://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:

  • At first, set to false the enable-welcome-root parameter in the virtual-server section:

              <virtual-server name=”default-host” enable-welcome-root=”false”>


  • Then, in your application, add a jboss-web.xml file that contains the root context for your application:




Adding a remote EJB client

A couple 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:

package com.packtpub.chapter4.ejb;

import java.util.List;

import com.packtpub.chapter4.entity.Property;

public interface SingletonBeanRemote {

public void delete();

public void put(String key,String value);

public List<Property> getCache();

public List<Property>  queryCache();


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:



public class  SingletonBeanRemoteImpl implements

SingletonBeanRemote  {

// Bean class unchanged


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:

static {

Security.addProvider(new JBossSaslProvider());


This will grant an 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:

package com.packtpub.chapter4.client;

import javax.naming.*;

import java.security.Security; import java.util.*;

import org.jboss.sasl.JBossSaslProvider;

import com.packtpub.chapter4.ejb.SingletonBeanRemote;

import com.packtpub.chapter4.ejb.SingletonBeanRemoteImpl;

import com.packtpub.chapter4.entity.Property;

public class RemoteEJBClient {   static {     Security.addProvider(new JBossSaslProvider());


public static void main(String[] args) throws Exception {     testRemoteEJB();

}   private static void testRemoteEJB() throws NamingException {

final SingletonBeanRemote ejb = lookupEJB();

System.out.println(“Got a remote Singleton EJB”);

// Adds an entry to the cache

 ejb.put(“key”, “value”);

// Retrieves the cache entries and prints them

List <Property> list = ejb.getCache();


}   private static SingletonBeanRemote lookupEJB() throws NamingException {

final Hashtable jndiProperties = new Hashtable();

jndiProperties.put(Context.URL_PKG_PREFIXES, “org.jboss.ejb.client.naming”);

 final Context context = new InitialContext(jndiProperties);

final String appName = “”;

final String moduleName = “as7project”;

final String distinctName = “”;

final String beanName = SingletonBeanRemoteImpl.class.getSimpleName();

final String viewClassName = SingletonBeanRemote.class.getName();

return (SingletonBeanRemote) context.lookup(“ejb:” + appName + “/” + moduleName + “/” + distinctName + “/” + beanName + “!” + viewClassName);



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 are 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.connection.default.host=localhost remote.connection.default.port = 4447


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 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 an authentication, our connection will be refused.

0 Responses on Deploying the web application"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.