Migrating Projects to WID 6.2 to 7.0

This morning, I started working on the WebSphere ESB v7.0 programming course – WA1916 WebSphere Enterprise Service Bus (ESB) v7.0 Programming Using WebSphere Integration Developer. I had to migrate a few projects from WID 6.2 to get started. I thought I will share a few interesting observations.

WID has  built in workspace migration wizard. When you bring in an old project – either through the import operation or CVS checkout – it will open the wizard automatically. In my case, I chose File > Import and then Other > Project Interchange.

I recommend migrating projects in two separate batches. First migrate the J2EE projects – that contain web services and web clients. Then migrate the business integration (SCA) modules. That will just simplify things.

Migrating J2EE Projects from WID 6.2

In WID 6.2, the J2EE projects were on a half way journey towards Java EE 5. They were J2EE 1.4 projects with some aspects of Java EE 5 thrown in – such as JAX-WS and JPA. That was done through WebSphere feature packs. Now, in WID 7, we have true Java EE 5 projects. So, what that means is, migration will involve two steps:

  1. Migrate the project structure from WID 6.2 to 7.0. This will be done by the workspace migration wizard that is started automatically when you bring the old project into WID 7 workspace.
  2. Migrate the specification level from J2EE 1.4 to Java EE 5. This will be done by a separate migration wizard.

So, let’s get started. Import the old J2EE projects (Enterprise application, web and EJB projects) into the workspace. The workspace migration wizard will start automatically after the files have been copied into the workspace. You can pretty much click Next in every screen. In the server runtime page, you will need to select a V7 server.


In my case, I selected WebSphere ESB Server v7.0. You can also select process server, if that is your runtime.

After the migration wizard finishes, if you have a JAX-WS web service in a web or EJB module, you will see an error message.


WebSphere Application Server v7.0 is not going to scan this module for JAX-WS annotations. You can enable scanning by setting the UseWSFEP61ScanPolicy property to true in the MANIFEST.MF file.

I must say, I was stumped by this. Fortunately, I could Google "UseWSFEP61ScanPolicy" which lead me to this InfoCenter page. Log story short – I had to migrate the projects from J2EE 1.4 to Java EE 5. Honestly, I did not originally consider that step, until I saw the InfoCenter page. So, in a way I am glad I saw that error message. In the next section, we will deal with Java EE migration.

Migrate Specification Level

Right click the enterprise application project and select Java EE > Specification Migration Wizard. Once again, you can pretty much click Next in every page and complete the wizard.

But alas, the error message remained. No amount of cleaning, rebuilding and re-validating got rid of it. Fortunately, I found an easy solution. Just export the projects as project interchange and then import them back in. That will get rid of the error.

Migrate SCA Modules

Import the SCA modules into the workspace. The workspace migration wizard will open. Change the server runtime to V7.0. And you are done!


No Comments

Changes in Java Webinar

I did a webinar a few weeks ago (just finding some time to blog) that covered many of the changes in Java technology over the past several years.  It was well attended (~110-120 people) which shows there is good interest in seeing where Java is going.

One of the main focus points of the webinar is that the landscape has changed quite a bit in the last several years and now going with some of the “tried and true” technologies may not be the best choice.  For instance, JSF should now probably be the de-facto choice of web framework instead of Struts from the past.  EJBs are no longer “poorly performing and hard to program” and are now in some ways easier to implement than the corresponding alternative in the Spring framework.  The Spring framework is still relative but is now probably best used in a different way than in the past.  There are also new options for application frameworks like Spring, most notably the Seam framework.  There is also a very different way you have to think about “Design Patterns” as many of them were developed long before these changes in Java Enterprise.

You can get the presentation and see a replay recording here:

Getting Ahead of Changes in Java Technology webinar 

One of the topics that got some questions was about some of the things in Java EE 6.  The webinar really didn’t get into a whole lot of detail on EE 6 and focused more on Java EE 5 since that is the version of the EE specifications that has broader support right now and that we see people actually starting to use.

Look for future blog posts and webinars where we will cover more details about some of the MANY changes in Java EE 6 in more detail.

No Comments

So You Want to Write a jQuery Plugin?

If you see yourself repeating the same jQuery code in a couple of pages, it is time to package that into a plugin. In this tutorial we will show you how to get started with jQuery plugin development.

Getting Setup

In your web server’s document root, create a folder called lab. We will create all files here.

In the lab folder, create a simple HTML file called plugin.html. Set the content of the file as follows.


<title>jQuery Labs</title>

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js">

<script type="text/javascript">
    	//jQuery code here


<!-- Body HTML here -->
<p class="c1">Hello World</p>


Save the file.

Open a web browser and enter the URL: http://localhost/lab/plugin.html. Make sure that you see the "Hello World" message.

Self Invoking Function

Before we get into plugin development, let’s learn about self invoking functions. This is a JavaScript technique, where a function is called by itself. This is great for functions that initialize things. This eliminates the need for the developers to write extra code to call this function.

Right above the </script> line, add these lines:

(function (msg){
}("I got called"));

Save changes. Refresh the browser. You should see the alert dialog.


A self invoking function has these syntax elements:

  1. The function may be anonymous or have a name. In the example above, it is anonymous.
  2. The input parameters are supplied within parenthesis right after the end of the function definition (or the last "}").
  3. The whole thing must be wrapped in parenthesis. This is crucial. Without that, you will get a JavaScript compilation error.

Self invoking function has many uses. In the next section, we will see how it plays a role for jQuery plugin development.

Delete the self invoking function before moving to the next section.

Writing a Simple Plugin

Every plugin is a function. This function is added to the prototype of the jQuery object. Recall, how any plugin is called:


The core function $("p1") returns a jQuery object. Here, plugin_func_name is a property added to the jQuery’s prototype. The value of the property is the plugin function.

Right above the </script> line, add these lines:

    $.fn.myPlugin = function() {
        alert("Cool plugin");

Here we see a self invoking function. The function is passed the jQuery global object as input. From within the function, we use the symbol $ for the input. Hence, $ is same as the jQuery object. All of this is just to simplify typing (typing $ is easier than jQuery). Using the self invoking function makes sure that the $ sign used here does not conflict with any previously declared variable by the same name ($) by any other toolkit (such as Prototype).

Anyway, the key thing is how we are adding the myPlugin property to the prototype of the jQuery object.

$.fn.myPlugin = function() {
    alert("Cool plugin");

Umm… what is this $.fn thing? Shouldn’t it be jQuery.prototype if we are trying to tweak the prototype of the jQuery object? First of all, jQuery and $ are one and the same object. Secondly, the "fn" property is same as the prototype. Somewhere within jQuery code, there is: jQuery.fn = jQuery.prototype. OK, fine. If you want to strictly play by the JavaScript rule, you don’t have to use self invoking functions of $.fn. You could so something like this and things should still work:

jQuery.prototype.myPlugin = function() {
    alert("Cool plugin");

But, self invoking function allows you to create private variables and functions. Something you need for complex plugins.

This is perhaps the simplest plugin anyone can develop. Now, we can start using our plugin.

Within the DOM ready handler function, below the line:

//jQuery code here



Save changes.

Refresh the browser or enter http://localhost/lab/plugin.html. You should see the plugin doing its thing.


This is a fully legit plugin. Except it doesn’t do anything that anyone cares about. In the next section, we will change that.

Work on Selected Elements

The core function $() does all the heavy lifting of selecting DOM elements in the page that match the passed selector rule. All a plugin has to do is do something with these elements.

We already know that the each() jQuery function is used to iterate over selected elements. We can use it from our plugin function.

Delete the line:

alert("Cool plugin");

In it’s place, enter the plugin code as shown below.

$.fn.myPlugin = function() {
    this.each(function() {
        this.innerHTML = "Your class is: " + this.className;

The "this" keyword within the plugin function points to the jQuery object. Hence, we can call the each() function. Within the iteration handler function, "this" points to the DOM element. Hence, we can use the DOM API and access properties like innerHTML and className.

Change the selector rule from where the plugin function is called.

    //jQuery code here

Save changes. Refresh the browser. You will notice that the text of the paragraph changes from "Hello World" to "Your class is: c1".


Add another paragraph below the existing one.

<!-- Body HTML here -->
<p class="c1">Hello World</p>
<p class="c2">Hello World</p>

Save changes. Refresh the browser.



In this tutorial, we learned the basic structure of writing a jQuery plugin. From this point, you can use the powerful jQuery API to create amazing and cool plugins. For more information on advanced plugin development topics, see this article.

No Comments

The jQuery Object

What does the jQuery core function – $() – actually return? So much emphasis is put on what this function takes as input, the return type is almost ignored.

The core function $() or jQuery() returns a jQuery object that is a collection of all DOM element objects that match the supplied selector rule. This jQuery object builds on top of the JavaScript Array API. For example, you can obtain the length:

$("p").length; //Number of paragraphs in the page.

To obtain a DOM element object in the collection, simply call get(index). The index is zero based. For example:

$("p").get(1).innerHTML; //Get the inner HTML of the second paragraph.

To call DOM API, you must get a DOM element from the collection. For example:

//Get all the p elements that are 
//children of the first div element.

//Following is an error. jQuery object is not a DOM element 
$("div").getElementsByName("p"); //Error!

While the jQuery object does not support DOM methods, it supports more methods than the JavaScript Array. These methods, like text() and css() form the heart of jQuery’s magic. Some of these methods have dual read and write use. For example, text(string) sets the inner text value of elements. While, text() returns the inner text. When you invoke a write method for the jQuery object, jQuery internally applies it to all DOM elements in the collection:

$("p").text("Hello!"); //Change text of all paragraphs to Hello!.

A getter function normally works on the first DOM element in the collection only.

$("p").text(); //Returns the text of the first paragraph only.

Converting Objects

We have already seen that to get a DOM object from a jQuery object, you call the get(index) method. But, how do we get a jQuery object for a DOM object? To convert a DOM element object into a jQuery collection do:


For example:

var e = document.getElementById("p1"); //Get the DOM element
var jObj = $(e); //Convert DOM element to jQuery object
jObj.hide(); //Call jQuery API

Which Object for Event Handlers?

The jQuery event handler registration functions like click() and hover() are just simple wrappers of the DOM event handler registration functions. In other words, these functions behave the same way as if you attached them using DOM’s addEventListener (or attachEvent for older IE). That means, the "this" keyword within the function points to the DOM element for which the function is being called. For example:

$("#myDiv").click(function() {

    this.innerHTML = "Clicked!"; //Straight DOM API
    $(this).css("background", "yellow"); //jQuery API


No Comments

WebSphere Application Server and IBM HTTP Server Cheat Sheet for Unix/Linux

Important Commands


  1. All of the WebSphere Application Server (WAS) commands below are located underneath the <PROFILE_ROOT>/bin directory.
  2. All of the IBM HTTP Server (IHS) commands are located underneath the <IHS_ROOT>/bin directory.

Start a server

./startServer.sh <serverName>

Stop a server

./stopServer.sh <serverName> -username <userName> -password <password>

Start a node agent


Stop a node agent

./stopNode.sh -username <userName> -password <password>

Start the deployment manager


Stop the deployment manager

./stopManager.sh -username <userName> -password <password>

Obtain server status for all servers on a node

./serverStatus.sh –all -username <userName> -password <password>

Obtain server status for a particular server

./serverStatus.sh <serverName> -username <userName> -password <password>

Start IBM HTTP Server

./apachectl start

Stop IBM HTTP Server

./apachectl stop

Start IBM HTTP Administration Service (Server)

./adminctl start

Stop IBM HTTP Administration Service (Server)

./adminctl stop

Important Log Files

WebSphere Application Server

SystemOut.log (located under <PROFILE_ROOT>/<profileName>/logs/<serverName>)


access_log (located under <IHS_ROOT>/logs) – contains requests from clients (browsers)

error_log (located under <IHS_ROOT>/logs) – contains error messages, including expansions of 404s

IBM HTTP Administration Service

admin_access_log (located under <IHS_ROOT>/logs) – contains requests from WAS

admin_error.log (located under <IHS_ROOT>/logs) – contains error messages (e.., related to propagation of plugin and starting/stopping web server)

WebSphere Plugin

http_plugin.log (located under <IHS_ROOT>/Plugins/logs/<webServerName>)

1 Comment

WebSphere Commerce 6.0 Install Problem

This morning, I was setting up a test machine with WebSphere Commerce 6.0 Express. I proceeded with typical installation. The installer kept giving error message about Windows user ID password – “User password entered is incorrect”.

This was most frustrating to say the least. I was entering the correct user ID and password. The user belonged to the Administrators group.

The solution was to install DB2 first. DB2 installer most probably adds the correct rights to the user.

Then, I did a custom install of Commerce. Typical install was not possible since DB2 was already installed. Things went smoothly.

No Comments

Decompile Android’s DEX File

Android uses a DEX archive in place of JAR. Also, the Java classes are compiled differently. To decompile the classes, you need to go through a few extra steps.

What Will You Need?

  1. Dex2Jar from http://code.google.com/p/dex2jar/
  2. A regular Java decompiler, such as JD from http://java.decompiler.free.fr.

Install these programs.

The Steps

First, extract the .apk file of the Android application.

jar  xvf  HelloWorld.apk

You will notice classes.dex file in the extracted folder.

Next, run dex2jar to convert the classes.dex file to a JAR file.

dex2jar.bat  classes.dex

This will produce an improbably named classes.dex.dex2jar.jar file.

Launch JD decompiler. Open the classes.dex.dex2jar.jar file and then view the .class files.


Profiling WebSphere Applications with IBM Support Assistant

One of the tools available for improving performance of Java applications is application profiling.  This involves using a tool to gather detailed information about how an application executes to look for various ways to improve performance.

Although profiling information is often done by developers it can also be done by administrators using tools in the IBM Support Assistant.  These tools are free, easy to install, and can help gather information to indicate there may be problems to pass along to developers to fix.  Also, developers who do not use Rational Application Developer, which also has built-in profiling tools, could use the free tools in IBM Support Assistant.

The primary tool we will describe here is the “Health Center” tool for IBM JVMs.  Note that the instructions here would be valid for Windows and other operating systems may be slightly different but this article provides links to resources for all operating systems.

Want More?

The steps in this article and the use of advanced troubleshooting tools available in the IBM Support Assistant will be some of the new content added to our new course, WA2148 WebSphere Application Server 8.5 Problem Determination.

Install Profiling Tools to IBM Support Assistant

The first step would be to install the IBM Support Assistant (ISA) Workbench if you have not already installed it.  The main tool we will show requires the 4.1 version of the ISA Workbench so if you have a previous version it is usually best to uninstall and then reinstall 4.1.  You can find complete details of how to install the ISA Workbench here.

Once you have the ISA Workbench installed open the program.  If this is the first time you have run the ISA Workbench it will often start a “First Steps” wizard to provide links to open the network and updating preferences, two important settings that you may need to configure to allow the ISA Workbench to connect to IBM servers through a firewall.  If you do not see this wizard but you know you need to set preferences you can also go to the File –> Preferences menu item.

If you use the First Steps wizard it will usually launch a tool to update the “add-ons” installed with ISA.  If this tool does not launch you can select Update –> Find New.. –> Tools Add-ons.  The updating tool may not appear immediately and you may see a progress indicator in the lower right corner.



When the tool add-ons are shown there may be different categories depending on the software you have chosen to support with ISA.  You will almost always have a ‘JVM-based Tools’ category though as many IBM products use Java.  Expand this category and check the IBM Monitoring and Diagnostic Tools for Java – Health Center option.  Unlike the screenshot below you may see several tools with similar names so make sure you choose the ‘”Health Center” as that is the tool we will highlight here.


Once the proper tool is selected press the Next button, accept the license and press the Next button again, and then press the Finish button to begin installing the tool.  You may not notice anything is happening except a progress indicator in the lower right corner.  Wait for the installation to complete.  Once the installation is complete you will be prompted to restart the ISA Workbench.  Click Yes to allow the restart.

Health Center Tool Architecture

The architecture of the Health Center tool is to run an “agent” within the Java JVM of the application you wish to monitor.  You will then connect to this agent from the tool run from the ISA Workbench.  If the application you are monitoring is on a different system than the ISA Workbench you will need to make sure to connect to it through firewalls and use the hostname of the machine running the application being monitored when connecting from the tool.

Since you will be installing the agent software and connecting to a live environment it is likely that you may not use the Health Center with production systems.  There are other tools that may be used with the ISA Workbench that would not require an agent to connect from another tool or would not require installing any software that is not already part of normal fixpacks since both of these procedures might violate change management policies on production systems.

In general though the kind of information you are looking for with the Health Center will be better to collect early in the deployment cycle so it may be better to use the Health Center with test and QA systems anyway which may not have quite the same policies against running the Health Center agent.


Launch Health Center Tool

To launch the Health Center tool click on the “Analyze Problem” shortcut on the main Welcome page of the ISA Workbench.


You can also get here by clicking the Launch Activity button and selecting Analyze Problem.


If the list of installed tools is not displayed, click the Tools tab along the top to display the list.

From the list of tools select the IBM Monitoring and Diagnostic Tools for Java – Health Center.  Remember you may have different tools than shown below.


Once the proper tool is selected click the Launch button in the lower left.

Leave the first page of the Connection Wizard open for the next section.


Install Health Center Agent

The Health Center agent is packaged as a Zip file that you extract to your Java JRE of the environment you want to use the Health Center with.  The best way to get the correct package is from the help topics of the Health Center ISA add-on.  The steps in this section will only need to be done once.

To do this click the “Enabling an application for monitoring” link from the first page of the Connection Wizard shown above.  The ISA Workbench help will open.

On the first page that appears click the link for “installing the Health Center agent” in the prerequisite section.


On the page that appears click on the link for the operating system you will be running the agent on.  This may be different than the operating system you are using for the ISA Workbench.  The files listed are packaged with the tool.


Save the Zip file to the machine you will be running the agent on.  Save it to the directory above the root of the Java Runtime Environment, or JRE.  For example on WebSphere Application Server the JRE is usually at <WAS_ROOT>/java/jre so you would save the Zip file to <WAS_ROOT>/java.

Unzip the Zip file to the folder above the JRE root directory, making sure to preserve the folders contained in the zip file.  As shown below this zip file will extract different files, the most notable the healthcenter.jar file, into different locations in the JRE.  Depending on your fixpack of the IBM JVM you may be replacing some Health Center files already present but this is OK as it is best to use the files provided with the version of the Health Center you are using.


Double check that the following file is present to make sure files were extracted properly:


Enable Health Center Agent

The steps for enabling the Health Center agent differ depending on what type of Java application you are using the agent with.  There instructions will show using WebSphere Application Server v7.0 which uses Java 6.0.

Since we are using WebSphere Application Server you want to expand the ‘Configuring WebSphere or Rational product environments’ and select the ‘Configuring WebSphere Application Server environments’ topic.


Start the WebSphere Application Server using the normal method.

Login to the Administrative Console.

Go to the server properties by selecting ‘Servers –> Server Types –> WebSphere application servers’ in the Admin Console navigation and clicking the name of the server.

Expand ‘Java and Process Management’ and click the ‘Process Definition’ link.

Click on the ‘Java Virtual Machine’ link and find the setting for ‘Generic JVM arguments’.

The next step is highly dependent on the Operating System and version of Java (including fixpacks) so check the Health Center help for the correct values.

For the ‘Generic JVM arguments’ we will use the following since we are using Windows and Java 6 with no fixpack:

-agentlib:healthcenter -Xtrace:output=C:\temp\perfmon.%p.out

(This assumes you already have a C:\temp directory, create one if you don’t as the setting above indicates where the agent will store data)


Double check the value you enter because an incorrect JVM argument can prevent the server from starting.  If you are using a “standalone” server that performs it’s own administration you might even need to manually edit the server.xml file if there are problems.

Click the OK button at the bottom of the page and then save the changes to the configuration.

Restart the server to use the new settings.

Connect from Health Center

Once your server is started with the proper settings you can return to the Health Center tool and connect.

Close the ISA Workbench help if it is still open.

Return to the Health Center connection wizard.  You can select File –> New Connection… with the Health Center tool active if you closed it.

If you are connecting to the server running on the same machine you can use ‘localhost’, otherwise enter the host information.  We are also using the default port although you can change this in the <JRE_ROOT>/lib/healthcenter.properties file you extracted with the agent installation.  In this case we are also not using authentication from the Health Center.  It is possible to enable this by following steps in the Health Center help topics.


Once your settings are appropriate for your setup click the Next button and the tool will search for connections.

Once a valid connection is found select it and press the Finish button.


The Health Center tool will begin collecting data.  Give it a minute to “catch up”, especially if you just restarted the server.


Using the Health Center Tool

Note: Although this section will give you a brief overview of some of the things you can use the tool for the Help topics have much more detail and great references for more information about certain kinds of problems.

The first thing you might want to do, especially if you are looking at an application running on a server that just restarted is to clear the data from when the server was starting.  This way you will not be including the garbage collection and other data from that time period.  You can clear the data previously collected by selecting Data –> Reset Data in the menu or using the corresponding button.

The Status view of the tool, which is the first page shown when you connect, will provide links to show the other perspectives and messages about certain types of problems that may be occurring.  Unless you are investigating a specific problem one of the best ways to use the tool is to run a load test of a deployed application and look if there are any messages in the Status view of potential problems.  If there are messages about problems you can click the link for the view that will help you investigate further.


The “Garbage Collection” perspective shows memory statistics and can do some analysis of memory problems.  Although it does not seem able to directly detect a “memory leak” you can get a live picture of the state of the memory heap size and look for the symptom of a memory leak where the memory keeps increasing.  You can then use other tools of the ISA Workbench to specifically investigate a memory leak problem.


The “Locking” perspective shows how much application code is waiting for locks between synchronized blocks of code.  This graph is a little tough to interpret because the height of the bars is always the “slow” value for the lock monitor.  Even if you sort the list below by something else the height of the bar will stay the same.  The bars will be colored red or yellow if a lock has a high “% miss”.  This is one of the primary things to look for as it indicates one thread is trying to get a lock while it is help by another thread and results in blocking.


The “Profiling” perspective lets you see how much time executing particular methods took.  You generally want to sort by the “Self” value to show the methods which took the highest time without the other methods it called included.  You can also sort by “Tree” but you have to remember that in a server application many things will be threads just waiting to execute or handle asynchronous I/O.  If you do sort by “Tree” make sure to scroll down and find the methods that are part of the application and not necessarily methods running WebSphere code (com.ibm…).


There are a few other perspectives and types of data available from the Health Center but these are generally the most useful to help diagnose the most common kinds of application problems.

One thing to keep in mind when using the Health Center is that the data is collected incrementally and meant more to show longer terms trends so it might be several seconds or a minute before you see what has been happening in the application due to recent activity.  One thing you can do is to select File –> Save Data to save the data from particular tests to analyze after the test has been performed.


Hopefully you can see that the Health Center tool available from the IBM Support Assistant Workbench is a tool that can help you quickly start diagnosing common application performance problems.  Based on the data from this tool you can use other tools provided with ISA to dig deeper into specific problems and provide developers or administrators information they can use to help resolve these issues.

Want More?

The steps in this article and the use of advanced troubleshooting tools available in the IBM Support Assistant will be some of the new content added to our new course, WA1849 Advanced WebSphere Application Server v7.0 Administration.


Advanced WebSphere 7.0 Administration Course Announced

At Web Age we have been seeing an increasing interest in using the improvements of the Java EE 5 specification in applications developed with RAD 7.5 and deployed to WebSphere Application Server 7.0.  This means that there are also those out there that are in need of learning about administration of the WebSphere 7.0 environment as well.

Although we have had our “core” WebSphere Application Server 7.0 Administration courses on Windows and Linux available for some time these courses do not always best serve those that are already familiar with WebSphere.  Those familiar with WebSphere are often looking for something that goes beyond the “basics” and delves into advanced topics and also focuses on the new features of the latest version.

To support this need we have recently posted an update of our advanced administration course for WebSphere 7.0.

WA1849 Advanced WebSphere Application Server 7.0 Administration

This class is suggested for any clients that have taken the “regular” WebSphere 7.0 admin class or all clients that have prior WebSphere v6.x experience.  Some of the differences between v6.x and v7.0 do not really impact the “regular” class much so one of the goals of the advanced class is to focus on many of the things that are different in 7.0 but also require some level of WebSphere knowledge.

This advanced class covers more on troubleshooting, performance, and scripting which have been of interest to many clients in addition to the advanced clustering topics also covered in the WebSphere 6.1 version of the class (WA1579).  The class also uses preconfigured Linux virtual machines with much of the basic software installed and configuration already performed so that the students in the class can focus on the advanced topics instead of the “basics” of installing WebSphere software.

As shown by our WebSphere 7.0 administrator course map, WA1849 is the preferred class for experienced WebSphere 6.x administrators.  WA1849 is also good as a follow-up to WA1700 (Windows) or WA1840 (Linux).

No Comments

Struts 2 Courses Announced

Struts has always been a popular web framework for Java because of it’s long history.   Because of this popularity, Struts was always very concerned with backwards compatibility.  This concern for backwards compatibility meant that Struts took a little while to come up with “what’s next”.  At Web Age we saw an increase in interest in JSF for those looking for alternatives to Struts.  Struts did release Struts 2.x which was a fairly major reinvention of what makes up the Struts framework.

Because of client interest we have posted two new Struts 2.x outlines recently.  These courses include hands-on labs ported to Struts 2.x in the appropriate IDE and lecture discussion using the popular published book “Struts 2 In Action”.  Each student will receive a copy of this book as part of the course.

WA1926 Introduction to Struts 2.x Using RAD 7.5

WA1927 Introduction to Struts 2.x Using Eclipse

Both of these classes are available and can be scheduled by contacting a Web Age sales representative.

No Comments