The JBoss Web application server was built with one primary goal in mind: to make it as dynamic and expandable (and scalable) as possible, without losing too much in performance or reliability.
Before starting JBoss (at least in a production environment), an adjusted configuration should be set up in the configuration directory (
<JBoss>/conf). By default, there is one subdirectory, called "default." These files can be adjusted, but the best practice is to copy them and adjust to your need. Therefore, JBoss can be started with the name of the configuration subdirectory (without the path) as the first parameter.
Inside this new configuration, adjust directory
jboss.conf to contain all the necessary
ClassPathExtensions, including JAR files needed to run JBoss (except the EJB JAR files, of course). Lt's have a look at the core configuration file:
jboss.jcml. It defines all the components JBoss needs to load at startup. The file must specify all the components needed, and every component not needed should be removed, which will speed up JBoss.
DataSources needs to be configured. If they're not necessary, then the default DBs delivered with JBoss should be kicked out. (JBoss comes with two default DBs: InterBase and Hypersonic.) For security reasons, the JMX HTML-Adaptor and JMX RMI-Connector should only be allowed to run if the network (ports) is secure; otherwise, someone outside can manage the application server (including stopping the server). Of course, an additional MBean can be added, too.
You might ask yourself, "Is this all?" Well, I didn't say we're finished. To help you understand the next part, I will first explain how a call from the client is handled in the J2EE-Container of JBoss. After the client calls a method, it will end up in the appropriate container (
Statefull Session or
Message). The container then calls the first Interceptor, which then hands it over to the next Interceptor, and so on until the last Interceptor is called. The last one is always the
ContainerInterceptor, which finally calls the method the client wanted to call. At last, the call is then reversed. Each Interceptor has the chance to execute its task before the business method gets called (which includes the stop of the execution) or prevents the return of the result of the business method.
Andreas Schaefer will be presenting the session, Using JBoss.org: A Java 2 Enterprise Edition-based Container at the O'Reilly Open Source Convention in San Diego, CA, July 23-27, 2001. Rub elbows with Open Source leaders while relaxing on the beautiful Sheraton San Diego Hotel and Marina waterfront. For more information, visit our conference home page or see our pre-conference coverage.
What are your thoughts on this application server? What do you prefer using?
Let's get concrete and assume that an ISP is offering clients the ability to host EJBs on its application servers. To bill clients, the ISP can just create an Interceptor and add it as the last Interceptor in the stack. To do so, you have to change either
jboss.xml. If the Interceptor is set in the
standardjboss.xml, you have to check if the client did not overwrite it in the application's
jboss.xml file. The Interceptor just has to check what the EJB is called and store the request in the billing system, assuming the ISP has a running JBoss application server and your client sends a new application containing EJBs.
Next, the client asks to store the data in its own database. To make everything a little easier, we also assume that the JDBC driver is already loaded. In JBoss, it is possible to add a new DB as a DataSource without restarting the application server. After creating the DB, the JMX management interface is accessed:
http://<server = name>:<HTML Adaptor Port>. The HTML Adaptor Port is by default on 8082, but can be changed in
jboss.jcml (please note that for this the HTML-Adaptor MBean must be specified in
Now a list of all already loaded JBoss components MBeans is displayed. Click on the "admin" button on the upper right corner and it will lead to the "Agent Administration" which allows you to create a new MBean.
Type in the
service=3DXADataSourec,name=3D<What ever DataSource = name> as Keys and
org.jboss.jdbc.XADataSourceLoader as Java Class.
The Action selection box should be set to "create." Then hit the "Send Request" button.
The confirmation page indicating a successful creation of the MBean shows up.
Now return back to the Agent View, and click on the newly created MBean.
Now, the DataSource attributes must be set, especially the
DataSourceClass, JDBC User, Password, Pool Name and the URL to the DB. Then, hit the "apply" button. Finally, hit first the "init" button to initialize the MBean and then the "start" button to start up the MBean. Please check the
StateString value so that it's set to "Started." If yes, then the DataSource is ready to rumble.
I hope you are impressed (at least a little bit), but this is not the end (even if it is for this article). You can easily write your own class, allowing you to use a different naming system like CORBA or SOAP without changing a class within JBoss. You just write your own ContainerInvoker and specify it in either
Therefore, if you don't need clustering or have a heavy-load Website, the JBoss Web application server is a really good choice, because it's a truly dynamic and expandable application server. For more on JBoss, go to jboss.org.
Andreas Schaefer is a system architect for J2EE at SeeBeyond Inc., where he leads application server development.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.