Introduction

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.

Back to top

New stuff

Community Edition V2.1 includes the following set of new features:

• Custom server assemblies: You can create server assemblies that contain only the functional components required by your application.
• Deployment Plan Creator wizard: An administrative console menu that helps you generate the appropriate deployment plan for Web 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.
• Community Edition Eclipse plug-in:The Eclipse plug-in now uses the Java Architecture on XML Binding (JAXB) instead of the Eclipse Modelling Framework (EMF).
• 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.

Back to top

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:

1. 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.
2. Deploy the sample jsp-examples-war to Community Edition V2.1.
3. You can launch the application and verify the functionality using http://localhost:8080/jsp-examples/.
4. 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/.
5. Log in using the default user name of system, and manager for the password.
6. 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
   
   
   
7. 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
   
   
   
8. 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:

1. In the Administrative Console under Applications, select Plugins, as Figure 3 shows:
   
   Figure 3. Plugin portlet in Administrative Console
   
   
   
2. 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
   
   
   
3. Now select the following plug-ins from the list displayed under Plugins in local server, and then click Assemble.
   • com.ibm.wasce.assemblies/wasce-boilerplate-minimal/2.1.0.0/jar
   • org.apache.geronimo.applications.examples/geronimo-jsp-examples/2.1.0.0/car
   • org.apache.geronimo.configs/axis/2.1.1/car
   • org.apache.geronimo.configs/axis2/2.1.1/car
   • org.apache.geronimo.configs/j2ee-corba-yoko/2.1.1/car
   • org.apache.geronimo.configs/jasper/2.1.1/car
   • org.apache.geronimo.configs/openjpa/2.1.1/car
   • org.apache.geronimo.configs/tomcat6/2.1.1/car
   
   
   Figure 5. Selecting plug-ins
   
   
   
4. The next screen (Figure 6) displays the list of all the plug-ins to include in the custom server. Click Install.
   
   Figure 6. List of all plug-ins to include in custom server
   
   
   
5. On the next screen (Figure 7) you should see a message indicating successful server assembly, that includes the location of the custom server (in our case <WASCE_HOME>/var/temp/assembly). Click Done.
   
   Figure 7. Successful server assembly
   
   
   
6. Next we need to test the assembled server. Shut down the existing one, and start the new server from <WASCE_HOME>\var\temp\assembly\bin\startup.bat.
7. Finally, you can launch the application using http://localhost:8080/jsp-examples/.

Note that our assembled server is a minimal server; you will not be able to get a graphical user interface for the administrative console.

For your reference, you might want to include these plug-ins in your custom server:

• org.apache.geronimo.plugins/console-tomcat/2.1.1/car: GUI-based administrative console
• org.apache.geronimo.plugins/sysdb-console-tomcat/2.1.1/car: GUI-based Database portlet in administrative console
• org.apache.geronimo.plugins/debugviews-console-tomcat/2.1.1/car: GUI-based Debug Views portlet in administrative console
• org.apache.geronimo.plugins/activemq-console-tomcat/2.1.1/car: GUI-based JMS console in administrative console
• org.apache.geronimo.plugins/plancreator-console-tomcat/2.1.1/car: GUI-based Deployment Plan Creator portlet in administrative console

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.

Back to top

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 .

1. 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.

   Currently we have the deployment plan shown in Listing 1:

  <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0"
         xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.2"
         xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">

  <dep:environment>
    <dep:moduleId>
      <dep:groupId>org.apache.geronimo.applications.examples</dep:groupId>
      <dep:artifactId>geronimo-jsp-examples</dep:artifactId>
      <dep:version>2.1.0.0</dep:version>
    </dep:moduleId>
    <dep:dependencies/>
    <dep:hidden-classes/>
    <dep:non-overridable-classes/>
  </dep:environment>
  
  <context-root>/jsp-examples</context-root>
  <!--<context-priority-classloader>false</context-priority-classloader>-->
  <security-realm-name>geronimo-admin</security-realm-name>
  <sec:security>
      <sec:default-principal>
          <sec:principal class="org.apache.geronimo.security.realm.providers.
                         GeronimoUserPrincipal" name="anonymous"/>
      </sec:default-principal>
      <sec:role-mappings>
          <sec:role role-name="tomcat">
              <sec:principal class="org.apache.geronimo.security.realm.providers.
                          GeronimoGroupPrincipal"name="admin"/>
          </sec:role>
      </sec:role-mappings>
  </sec:security>
</web-app>

2. Delete the deployment plan from the jsp-examples-war-2.1.0.0.war archive.
3. Launch the Community Edition administrative console and log in using the default user name and password.
4. Under Applications, select Plan Creator, as Figure 8 shows:
   
   Figure 8. Plan Creator portlet in Administrative Console
   
   
   
5. 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
   
   
   
6. 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
   
   
   
7. 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
   
   
   
8. 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.

9. 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.
   
   
10. The next screen displays the generated deployment plan, as Listing 2 shows:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1">
    <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
        <dep:moduleId>
            <dep:groupId>default</dep:groupId>
            <dep:artifactId>jsp-examples-war-2.1.0.0</dep:artifactId>
            <dep:version>1.0</dep:version>
            <dep:type>war</dep:type>
        </dep:moduleId>
    </dep:environment>
    <context-root>PlanCreatorTest</context-root>
    <security-realm-name>geronimo-admin</security-realm-name>
    <app:security xsi:type="sec:securityType" 
                    xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0" 
                    xmlns:app="http://geronimo.apache.org/xml/ns/j2ee/application-2.0" 
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <sec:role-mappings>
            <sec:role role-name="role1">
                <sec:principal name="TestUser " class=
                   "org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>
            </sec:role>
            <sec:role role-name="tomcat">
                <sec:principal name="TestGroup " class=
                   "org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"/>
            </sec:role>
        </sec:role-mappings>
    </app:security>
</web-app>

11. Select Deploy WAR, as Figure 14 shows:
    
    Figure 14. Deploying WAR with deployment plan
    
    
    
12. 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
    
    
    
13. 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.
    
    
    

Back to top

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:

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:

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

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:

Back to top

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.

1. Launch the administrative console and login using default user name and password
2. 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
   
   
   
3. 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
   
   
   

Back to top

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:

1. Launch the administrative console and log in using the default user name and password.
2. 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:

1. Click Add a Server, as Figure 23 shows:
   
   Figure 23. Adding a server in Monitoring Portlet
   
   
   
2. 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
   
   
   
3. 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
   
   
   
4. 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..
   
   
5. 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
   
   
   
6. 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:

   • My Server shows the status, added timestamp, modified timestamp, IP Hostname, and snapshot duration for the current configuration.
   • 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.
   
   
   
7. 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
   
   
   
8. 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.

1. From the Monitoring portlet, select +Add Graph, as Figure 30 shows:
   
   Figure 30. Adding a graph
   
   
   
2. 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
   
   
   
3. 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:

1. In the Monitoring portlet select +Create View.
2. 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
   
   
   
3. 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
   
   
   

Back to top

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.

Back to top

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.

Back to top

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.
• Some new samples have been added, including:
  • Bank- demonstrates EJB 3.0 Session Bean, JPA and OpenEJB client technologies.
  • jms-mdb-sample- demonstrates the Message-Driven Bean in EJB 3.0
  • sendmail- demonstrates the Mail Session in Community Edition.
• 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.

Back to top

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.

Resources

Learn

• Migrating from Apache Tomcat Version 6.0.x to WebSphere Application Server Community Edition V2.1
  
  
• Developing JPA Applications with WebSphere Application Server Community Edition
  
  
• Community Edition support site
  
  
• WebSphere Application Server Community Edition documentation
  
  
• WebSphere Application Server Community Edition samples
  
  
• Apache Geronimo site
  
  
• Develop applications on all the Java EE5 APIs
  
  
• Get to know Java EE 5
  
  
• Clustering in Community Edition
  
  
• Apache Geronimo samples
  
  
• WebSphere Application Server Community Edition Technical Support offerings
  
  
• WebSphere Application Server Community Edition resources
  
  
• developerWorks Open Source zone
  
  

Get products and technologies

• Download Community Edition
  
  
• Community Edition Eclipse plug-in update
  
  
• ActiveMQ
  
  
• Apache Tomcat
  
  
• OpenEJB
  
  

Discuss

• developerWorks WebSphere Application Server Community Edition and Apache Geronimo forum
  
  
• developerWorks Open Source forum
  
  

About the author

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.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• New stuff
• Custom server assemblies
• Deployment Plan Creator wizard
• GShell
• Expert mode
• Monitoring console plug-in
• WADI clustering
• Community Edition Eclipse plug-in
• Other enhancements
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers