What's new in WebSphere Application Server Community Edition V2.1

Explore the new features in WebSphere® Application Server
Community Edition V2.1, including the ability to execute Geronimo commands
using GShell, create multiple server assemblies from you own set of servers,
and fully control the server through Expert mode and a new Monitoring portlet.
This release improves on what is already the most powerful open source
application server available.

Ashish Jain is a Software Engineer working for Level 3 Technical Support of IBM WebSphere Application Server Community Edition. He received a Bachelors of Engineering in Computer Science from NITK Surathkal, and joined IBM in 2005 as an ELTP.

Introduction

Download Community Edition V2.1 now!IBM WebSphere Application Server Community Edition V2.1 is
available for no charge to use and deploy. Download it now to get started.

With a focus on improving usability and consumability, IBM has announced
its new release of WebSphere Application Server Community Edition
(hereafter Community Edition). Community Edition V2.1 is packed with a
jumbo set of features that further establish it as one of the most
powerful Javaâ¢ EE5 application servers. Letâs take a
tour of the features included in the latest release of Community
Edition.

Community Edition is a fully certified Java Platform Enterprise Edition
5(Java EE5) application server based on Apache Geronimo V2.1.1. This
article walks you through a whole set of new features, including custom
server assemblies, deployment plan creator wizard, GShell, enhanced
administrative console, Global JNDI support and many others. This release
also includes a new development and user guide which makes it even easier
to develop, deploy and run applications.

GShell:A command-line
processing environment for the execution of Geronimo commands. GShell
is an extensible environment and includes support for editing, command
history, and tab completion.

Expert mode: Gives expert
users complete control off the processes running on the Community
Edition server. By default you cannot modify critical processes, but
this new mode lets you override that setting.

Monitoring console plug-in:
Provides monitoring support in the Geronimo administration console.
The monitoring console can gather statistics and performance data from
multiple Geronimo servers and graphically display this data to
users.

WADI clustering: You can now
use Web Application Distribution Infrastructure (WADI) to support
clustering of Web applications for Geronimo configurations that use
the Tomcat Web container (WADI support for Jetty was in previous
releases). You can also now deploy applications to
administratively-defined groups of Geronimo servers.

Other enhancements: Community
Editions sports a new look and feel, other usability improvements, a
component-based administrative console, and support for additional
databases and operating systems. Weâll explore these
enhancements at the end of the article.

Community Edition V2.1 includes several new components and modules, as
shown in Table 1. The new modules are marked in bold.

Table 1. Comparison between modules in Community
Edition V2.0 and V2.1

Custom server assemblies

The default download of Community Edition is a fully compliant, Java
EE5-certified server assembly. Depending on your business requirements you
may not need a complete server but just require a part of it. For example
if your application comprises only the Web tier, you might only need
Tomcat and exclude the other modules like OpenEJB, Active MQ etc.
Previously extracting a custom server was a build-time operation, but with
Community Edition V2.1 you can get a a customized snapshot of the existing
server during runtime. There are two approaches to extract a custom
server:

Application centric: You select one or more plug-ins
required for your application to run successfully.

Function centric: You select the desired set of
features required for your development environment.

We will discuss creating a custom server in great detail in the next
sections. But first we need to understand the basic Community Edition
architecture. It provides a plug-in architecture where servers are
assembled completely out of the plug-ins. Every module in Community
Edition is a plug-in, and each plug-in has associated dependencies. So we
need to make sure that our assembled server has all the plug-ins it needs
to operate.

In our sample we use an application-centric approach to define the contents
of our custom server. We are using jsp-examples-war from our
existing Community Edition samples (available with the Community Edition
download). Follow these steps to create the custom server assembly:

Modify the deployment plan for the application. This step is required
because the default deployment of the sample installs the application
as WAR, whereas Community Edition recognizes a plug-in as a CAR. Add
the <dep:type>car</dep:type> tag to the
deployment plan.

Next we identify the functional components and dependencies required
by our application. This step can be simplified by using the
Dependency Viewer portlet in the administrative console. Launch the
administrative console using http://localhost:8080/console/.

Log in using the default user name of system, and
manager for the password.

On the welcome page under Debug Views, launch the Dependency
Viewer portlet as shown in Figure 1:

Figure 1. Dependency Viewer portlet
in administrative console

Since we have deployed a Web application, select
WebModule. Under WebModule,
select org.apache.geronimo.applications.examples/geronimo-jsp-
examples/2.1.0.0/car-> dependencies, which displays
the various dependencies required by our Web application (see Figure
2):

Figure 2. Dependencies for
jsp-examples-war application

To get a minimal working server we also need to include the
geronimo-boilerplate-minimal plug-in for start,
stop and other functionalities.

We have now identified the dependencies required for our custom server.
Next we assemble a custom server out of all these dependencies:

In the Administrative Console under Applications,
select Plugins, as Figure 3 shows:

Figure 3. Plugin portlet in
Administrative Console

Next select Assemble a server. On the next screen,
enter org.apache.geronimo.customserver for the
groupId and TestServer for
the artifactId, as Figure 4 shows:

Figure 4. Artifacts for the
assembled server

Now select the following plug-ins from the list displayed under
Plugins in local server, and then click
Assemble.

As you can tell from our example, the custom server is a powerful feature
that further harnesses the modular, extensible Geronimo plug-in
architecture. You can quickly assemble numerous types of servers out of an
existing running server.

Deployment Plan Creator wizard

To simplify the creation of server-specific deployment plans (like
geronimo-web.xml), Community Edition now has a new portlet
called Plan Creator in the administrative console. Plan Creator takes a
Web application archive (WAR) and walks the user through a sequence of
steps to auto-generate the geronimo-web.xml file. It does not
yet support creating geronimo-application.xml and
openejb-jar.xml from EARs and EJB-JARs.

Some of the salient features of the Deployment Plan Creator include:

EJB, EJB Local, JDBC Connection Pool, JMS Connection Factory, JMS
Destination, JavaMail Session & Web Service references
declared in the Web-applications are auto discovered. You resolve them
by listing available resources in the server environment to which they
can be linked.

Any of the references described above that are declared inside the
Java classes through annotations are also auto
discovered.

Simplified configuration of security.

We will illustrate this with the jsp-examples-war application
available in the Community Edition samples .

In jsp-examples-war-2.1.0.0.war, locate the Web
application deployment plan
(geronimo-web.xml) in the application
archive under WEB-INF.

Delete the deployment plan from the
jsp-examples-war-2.1.0.0.war
archive.

Launch the Community Edition administrative console and log in using
the default user name and password.

Under Applications, select Plan Creator,
as Figure 8 shows:

Figure 8. Plan Creator portlet in
Administrative Console

In the next screen, click Browse and select
jsp-examples-war-2.1.0.0.war. Click
Configure, as Figure 9 shows:

Figure 9. Selecting Web archive for
creating deployment plan

The next screen suggests a Web application identity and class path
configuration for our environment. You can set the
WebContextRoot to
PlanCreatorTest, and leave the rest of the values as the
defaults, as Figure 10 shows. Click Next.

Figure 10. Configuring Web
application identity and class path

The next screen displays the configuration for security realm and
role mappings. Select Principal for the
role1 field. The
Name and Class fields then
appear. Name it TestUser, and select User
Principal for the Class, as Figure 11
shows. Click Add.

Figure 11. Selecting the
class

You should now see the Principal, Name and Class displayed as added
to the deployment plan, as Figure 12 shows:

Figure 12. Configuring role mapping
for role1

Next select Principal for the
tomcat field. Name it TestGroup,
and select Group Principal for the
Class field. Select Add, as
Figure 13 shows.

Figure 13. Configuring role mapping
for tomcat

You should now see the Principal, Name, and Class displayed as
added to the deployment plan. Select
Next.

The next screen suggests dependencies to select for the application.
Our application does not have any, so we will keep the default
selection. You could select dependencies like ejb, database pool, jms
resources etc, but they arenât required. Select
Next.

The next screen displays the generated deployment plan, as Listing 2
shows:

Figure 14. Deploying WAR with
deployment plan

You should see a message indicating the successful deployment of our
Web application. Select Launch Web App to launch the
Web application, as Figure 15 shows:

Figure 15. Launching the Web
application

As you can see in Figure 16, the application launches with a context
root PlanCreatorTest. However, the original deployment
plan (the one packaged with the Web application) had
jsp-examples as the context root.

Figure 16. Launched application with
context root as PlanCreatorTest.

GShell

GShell is a framework for building rich command line applications. GShell
is a command line processing environment for executing most of the
Community Edition commands. Table 2 displays the various GShell
commands:

Table 2. Gshell commands

Commands

Description

help or ?

Display help information

echo or print

Print arguments to STDOUT

source or .

Load a file or URL to the
current shell

clear

Clear the terminal screen

set

Set a variable

unset

Unset a variable

exit or quit

Exit GShell

geronimo/start-server

Start a server

geronimo/stop-server

Stop the server

geronimo/wait-for-server

Wait for the server to start

geronimo/start-client

Start an application client

deploy/connect

Connect to a WASCE server

deploy/disconnect

Disconnect from a WASCE server

deploy/deploy

Deploy a module

deploy/redeploy

Redeploy a module

deploy/undeploy

Undeploy a module

deploy/distribute

Distribute a module

deploy/start

Start a module

deploy/restart

Restart a module

deploy/stop

Stop a module

deploy/list-modules

List modules

deploy/list-targets

List targets

deploy/list-plugins

Install plug-ins into the
server

deploy/install-library

Install library

deploy/install-plugin

Install a plug-in

deploy/assemble

Extract a WASCE server from the
current one

Letâs look at an example of using GShell. Community Edition has
a batch file gsh.bat to start GShell, available in
<WASCE_HOME>/bin. Launch GShell by running
gsh.bat from a command prompt, as Figure 17 shows:

Figure 17. Starting GShell

To start the server using GShell, enter the command
geronimo/start-server, as Figure 18 shows:

Figure 18. Starting a server using
GShell

To list the modules deployed on the server, enter the
command deploy/list-modules. Enter the default user name and
password, as Figure 19 shows:

Figure 19. Listing the modules deployed on
the server

Expert mode

In the Community Edition administrative console, under
Applications, various portlets (WebAppWARs, system
modules, application EARs, EJB JARs, J2EE Connectors, app clients) display
the various modules (Web applications modules, system modules, enterprise
application modules, EJB modules, connector modules, application clients,
respectively). From these portlets you can start, stop, restart and
uninstall various modules. The default console displays these operations
grayed out for various modules.

Expert mode lets advanced users have more control over the processes
running on the Community Edition server. By default you cannot modify
critical processes. However, the Expert mode option enables full control
over these processes, and is embedded into all the portlets previously
mentioned. The following example shows you how to use Expert mode in
Community Edition.

Launch the administrative console and login using default user name
and password

Under Applications, select WebAppWARs. As you can
see in Figure 20, stop, restart and uninstall commands for various
modules are grayed out.

Figure 20. Default display of
WebAppWARs portlet

Select the checkbox for Expert User on the top left
of the Installed Web Applications screen.
Youâll see that the grayed out commands are enabled, as
shown in Figure 21. Now you have full control of all the modules
installed on the server.

Figure 21. WebAppWARs portlet after
enabling Expert User

Monitoring console plug-in

The health of the server can be critical; anticipating server crashes is
crucial to any running application. Usually such server crashes ends with
lots of troubleshooting and loss of critical data. To avoid such
catastrophic situations, you need to continuously monitor server health
and reconfigure it to perform at an optimum level. This monitoring in turn
increases the productivity of your production environment. To address this
issue, the Community Edition V2.1 administrative console is integrated
with a new Monitoring plug-that continuously monitors various statistics,
such as:

Transaction Manager

JVM

AJP/Web/WebSSL connector

ThreadPool

Web application

However, you should only monitor your required components, rather than
enabling everything. The rule of thumb is well established -- the more
components you monitor, the greater the impact on server performance.

The default installation of Community Edition is pre-deployed with the
Monitoring plug-in. This portlet has three panes: View, Servers and
Graphs. Letâs discuss each one of them in turn in the context
of an example:

Launch the administrative console and log in using the default user
name and password.

In the console navigation, under Server, select
Monitoring to launch the portlet. You will see
the View, Servers and Graphs panes. On the right side you see
+Create View, +Add Server,
+Add Graph, as Figure 22 shows. You use these to
add a new View, Server and Graph respectively.

Figure 22. Default View of
Monitoring portlet

Servers

Before we can start working with our Monitoring plug-in, we need to add a
server. Using this pane, you can add multiple instances of Community
Edition, which allows centralized monitoring of multiple machines. The
following steps illustrate adding a server using the Monitoring
plug-in:

Click Add a Server, as Figure 23 shows:

Figure 23. Adding a server in
Monitoring Portlet

On the next screen fill in the various fields as shown in Figure 24,
and click Add.

Name: MyServer

IP/Hostname: localhost

Protocol: EJB

Port: 4201

Username: system

Password: manager

Figure 24. Configuring the server in
the Monitoring portlet

You are redirected to the default view of the Monitoring portlet, but
this time you see a message reporting successful addition of the
server, as Figure 25 shows. Also, the Servers pane has a new entry
called MyServer. Currently the status of the query is
stopped. Click +Enable Query to start
the snapshot collection of data.

Figure 25. Enabling snapshot
collection of data

Now you should see the status of the query as
Online, which collects a snapshot every 5
minutes. You can modify this by clicking Edit under
Actions..

On this screen change the Snapshot Duration to 1 minute, and click
Save. You should see a message saying
âServer has been updatedâ. Select
Monitoring to go back to the default view of the
portlet.

Figure 26. Editing the existing
server configuration

In the Server pane, select MyServer to display the
various statistics being monitored by that server. Figure 27 shows the
statistics:

Figure 27. Various statistics being
monitored by our MyServer configuration

Letâs take a closer look at various fields and
functionalities on this page:

Live Statistics shows the various components
currently being monitored (for example JVM, Tomcat AJP
Connector, Tomcat Web Connector, Tomcat Web SSL Connector,
activemq-console-tomcat). You can also see two Web
applications being monitored: SimpleJSF and
jsp-examples-war-2.1.0.0. Each of these is
associated with various fields.

On the right hand side you can see Statistics
Collected, which shows the statistics currently
being collected for the components. By each field you can see
a Ã, which can be used to stop the
monitoring of a component.

The Statistics Available panel shows the
various components available to be included in the current
monitoring configuration. Selecting + adds a
component to the Statistics Collected panel,
causing the server to start monitoring the newly added
component.

Actions panel provides various options to
configure the current server monitoring configuration.

On the same screen, try selecting some link under Live
Statistics. Letâs select the Busy
Threads Max link under
TomcatAJPConnector, as Figure 28 shows:

Figure 28. Selecting Busy Thread Max
under TomcatAJPConnector

This link launches a portlet for adding a graph for the selected
property, as shown in Figure 29. This is an easier way to create
graphs, since a few fields are already populated by default. However
we will look at creating a graph from scratch in the next section.

Figure 29. Adding a Graph through
MyServer configuration

Graph

You can use this pane to create customized graphs. It also lets you perform
mathematical operations like addition, subtraction, division, and
multiplication on two statistics. Letâs add a graph for the
current MyServer configuration.

From the Monitoring portlet, select +Add Graph, as
Figure 30 shows:

Figure 30. Adding a graph

On the next screen, fill in the following values, as shown in Figure
31. Click Add.

Server: MyServer-localhost

Name: TomcatAJP_BusyThread

Description: This is to monitor the Busy
thread Max for Tomcat AJP Connector

X Axis label: Busy Threads

Y Axis label: Time

Timeframe: 5

Mbean: TomcatAJPConnector

Data series: As-is; Busy Threads Max

Math operation: none

Figure 31. Filling the form for
adding a graph

You return to the default view of the Monitoring portlet, with a
message reporting the successful addition of the Graph. Select the
added graph to display the graph, as Figure 32 shows:

Figure 32. Displaying graph

View

Because of the many different graphs, Community Edition uses the concept of
a "view" to bundle related graphs together for more manageable use. For
example, you can bundle together all graphs related to a specific server,
or all graphs showing the throughput of servers. Letâs walk
through how to create a view:

In the Monitoring portlet select +Create View.

On the next screen give a name and description for the new view. You
also see a Graphs field which displays a list of
graphs available with the current configuration. So far we have added
only one graph it, so thereâs not much to choose from..
Select the check box and save the configuration as shown in Figure 33:

Figure 33. Configuring a
View

You return to the default view of the Monitoring portlet. Select
MyView to view the current configuration, which
displays the graph you added.

Figure 34. Displaying the MyView
configuration

WADI clustering

An application server cluster is a group of servers that transparently
provide enterprise services, such as Servlets and JavaServer Pages (JSP)
support, as if it was a single server. The servers, typically running on
separate systems, exchange messages to synchronize data, allowing any
individual node to process requests for a distributed application and to
take over a user's session when its node fails. Configuring multiple
servers into a cluster is commonly called clustering.

Currently, Community Edition implements clusters using the session
replication support from either Apache Tomcat or WADI (Web Application
Distributed Infrastructure).

Tomcat clusters have some limitations.

They do not replicate stateful session Enterprise JavaBeans (EJBs).
You need to avoid stateful session EJBs in your distributed
applications.

They do not replicate dynamic updates to the Java Naming and
Directory Interface (JNDI). You need to configure all the JNDI names
used by your distributed applications in every node of the
cluster.

They do not replicate distributable Web applications to other nodes
in the cluster. You need to deploy your distributable Web applications
to every node.

Community Edition V2.1 improves on Tomcat clusters in the following
ways:

You can now use WADI with Tomcat configurations of Community Edition,
to support the replication of HTTP Session state among multiple
Community Edition servers.

You can now deploy applications to administratively-defined groups of
Community Edition servers, which makes it easier to manage a single
application across a number of Community Edition servers.

You can now use WADI to support clustering of Web applications for
configurations that use Tomcat Web containers. To cluster these
components, their deployment descriptors are augmented with specific XML
elements. These elements define various clustering parameters controlling
how the underlying WADI's components are wired and set-up upon application
deployment.

WADI also provides the concept of farming:

Farming -provides cluster-wide hot deployment of Web
applications. In a server farm, you deploy a Web application by
copying an application's WAR file to only one node in the cluster.
Farming takes care of deploying the Web application across the entire
cluster. Similarly, removing the WAR file from a single cluster node
removes the Web application from all the nodes in the cluster. You can
deploy a configuration to a cluster of Community Edition servers via a
single logical deployment step. Once deployed to a cluster, this
configuration can then be transparently started, stopped or removed
across all the cluster members.

Farm deployment- Deploying a application to
configured members of cluster.

For more information, see the Community Edition documentation on clustering.

Community Edition Eclipse
plug-in

The Community Edition Eclipse plug-in (hereafter WEP) v2.1 has undergone a
major architectural change in its model framework, from the Eclipse
Modelling Framework (EMF) to the Java Architecture on XML Binding (JAXB).
This was done to enables some major improvements in WEP's Deployment Plan
Editors. So expect some intelligent editors in a future release!

Also, with v2.1 WEP has shed a lot of weight -â the WEP
footprint is now just 5MB, down from 13MB in the previous release. In
addition, WEP contains numerous bug fixes, leading to a smoother
experience using WEP.

Other enhancements

The administrative console is now component-based to mirror the
server capabilities. When you create a custom server assembly, only
the corresponding portlets that are used by the selected functions or
modules are incorporated.

Community Edition V2.1 now includes support for IBM DB2 8.2, 9.1 and
9.5 JDBC drivers as well as Oracle Real Application Cluster (RAC)
support.

Community Edition V2.1 is now compatible with Red Hat Fedora 9,
Ubuntu 8.04 Long Term Support(LTS) and recommends the AIX Version 6
Update 1 operating system. Java support includes recommendations for
IBM Java 32bit/64 bit SE 5 SR6b and compatibility with Sun Java 32bit
SE 5 Update 15 or later.

The Community Edition console has been rebranded with new look and
feel. Several enhancements have been applied to the administrative
console to improve the user experience. Enhancements include renaming
various links on the left pane of the console navigation for increased
usability, for example under Server, the JVM portlet has
been renamed to Java System Info, and
Common Libs has been renamed to
Repository.

Various component modules have been updated in Community Edition
V2.1. Please see Table 1 for an updated list of
modules.

The config.xml in Community Edition V2.1 now includes all the
available attributes for Tomcat Web, AJP and SSL attributes.

A new gbean TomcatClusteringBuilder helps with
clustering support. Config-substitution.properties has
also been modified to include various new configuration parameters
like
MaxThreadPoolSize, ResourceBindingsQuery, clusterName, ResourceBindingsFormat,and TmId.

Conclusion

As said the saying goes:- âTrue maturity comes with
exploring all possibilitiesâ. The new options
explored in this release bring Community Edition much closer to maturity.
The Community Edition teamâs three years of rigorous
development, testing, and gathering feedback has paid off in this release,
and ongoing development provides continuous improvements. As
weâve seen, with this release users can execute all Geronimo
commands using, GShell, create multiple server assemblies from their own
set of servers, and fully control the server through Expert mode and the
Monitoring portlet. Numerous other features integrated in Community
Edition V2.1 make it easier to configure, develop, deploy and run
applications. We have just touched on the high points of the release.
Explore the new features in detail by visiting the sites listed in the
Resources section; this article is just the beginning.

The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.