It's easy to guess that these days I have moving some projects between IDEs (WSAD to RAD to WAS 6.1 toolkit). The issue I have spent most time fixing is this exception…

uncaught init() exception thrown by servlet action: javax.servlet.UnavailableException: Parsing error processing resource path WEB-INF/struts-config.xml

at org.apache.struts.action.ActionServlet.handleConfigException(ActionServlet.java:769)

at org.apache.struts.action.ActionServlet.parseModuleConfigFile(ActionServlet.java:741)

at org.apache.struts.action.ActionServlet.initModuleConfig(ActionServlet.java:687)

at org.apache.struts.action.ActionServlet.init(ActionServlet.java:333)

at javax.servlet.GenericServlet.init(GenericServlet.java:256)

<more …>

Obviously when you see a parsing error, you would think your struts-config.xml file is either not well formed or not valid. I checked and double checked with various xml tools only to find out that my struts-config was fine. Upon close inspection of my web.xml file, I realized that the file defined struts-config.xml like this

<init-param>

<param-name>config</param-name>

<param-value>WEB-INF/struts-config.xml</param-value>

</init-param>

This is incorrect. The location of struts-config.xml should be defined relative to the web application root like this:

<init-param>

<param-name>config</param-name>

<param-value>/WEB-INF/struts-config.xml</param-value>

</init-param>

Notice the slash in front of WEB-INF. This tells the parser to look for struts-config.xml relative to the web application root. If you don't put the slash, the parser looks for the file relative to the current location (i.e. relative to the web.xml file in which the entry is defined).

Surprisingly, the entry without slash worked fine in WSAD (I don't know why) but when moved to RAD, it gave me the exception. What makes it worse is the exception reporting. Looking at the stack trace there is no way to know what the actual problem is. To an extent all these xml based frameworks suffer from this problem but more on that later.

JDK 1.4 added a keyword called assert. You can use assert on a boolean expression that you believe will be true. If the expression is not true, the program throws an error. Using assert (and not receiving any errors) increases your confidence in your code. You can use assert (as opposed to System.out) to debug your code. Visit this link to learn more about assert: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

So far so good but I wouldn't be writing this blog entry if assert was this simple. Since assert was NOT a keyword prior to jdk 1.4, you could use it as an identifier as in

private String assert;

Obviously, jdk 1.4 would give you an error because assert is a keyword in jdk 1.4 and the statement above isn't the legal use of assert. To avoid this problem, jdk 1.4 compiler was designed to be 1.3 compatible by default. So, if you write code in jdk 1.4 using assert as an identifier and compile it, you will simply get a warning because for .class files, it uses jdk 1.3 compatibility. 

The so called 'feature' described above caused me some trouble when I recently switched my IDE. My code was using assert in jdk 1.4 way (as in)

assert idao != null;

When I compiled my code, RAD compiled it against jdk 1.3, thought assert was an identifier and gave me an error. The link above explains that you must use -source 1.4 flag to correctly recognize assert statements.

To fix this,

• I went to Window > Preferences > expand Java > select Compiler > Compiler and Classfiles tab
• Unchecked Use default compliance settings
• Selected 1.4 in both source and .class files compatibility

This may not remove all the compilation errors however. RAD (and eclipse for that matter) by default uses compiler settings at project level so Window > Preferences settings may not have any effect. This makes sense because not all the projects in a workspace may belong to a single application. You may have some projects in an old application that you might want to compile against an older version of jdk.

To fix this,

• Right click the project and go to Properties
• Select Java Compiler
• Either set source and .class files compatibility to 1.4 OR choose workspace settings

The only pain point is, if you are migrating an application with many projects to a new RAD or WAS 6.1 toolkit, you may have to do this for all the projects.

Most application that allows multiple windows allow you to switch between them using ctrl+tab key. Not eclipse. It uses ctrl+F6 and so does RAD etc. But this can be changed. To change the key that switches between classes (small windows within eclipse),

• go to Window > Preferences > expand Workbench > select Keys
• In the Category dropdown, select Window
• In the Name dropdown, select Next Editor
• Put the cursor in the Name field in the Key Sequence section and press ctrl+tab. Do not type ctrl+tab, press those keys
• Click Add, the key assignment is added to Assignments section
• Optionally, remove the ctrl+F6 assignment by selecting it and clicking Remove button
• Click Apply and then OK buttons to close the dialog box

If you are using eclipse 3.1.2 OR WebSphere Application Server toolkit v6.1, the procedure is similar but the buttons are little different:

• go to Window > Preferences > expand General > select Keys
• In the Category dropdown, select Window
• In the Name dropdown, select Next Editor
• Put the cursor in the Name field in the Key Sequence section and press ctrl+tab. Do not type ctrl+tab, press those keys
• Click Add, the key assignment is added to Assignments section
• Optionally, remove the ctrl+F6 assignment by selecting it and clicking Remove button
• Click Apply and then OK buttons to close the dialog box

There are all kinds of considerations when migrating an application from WAS 5.x to 6.x. But I want to talk about moving projects from WAS 5.x to WAS 6.x within Rational Application Developer. This change could come in two flavors:

1. Moving from WSAD to RAD
2. Moving from RAD using WAS 5.1 to WAS 6.0

Before we talk about specific steps to follow, it must be noted that every J2EE project in WSAD or RAD uses at least 2 variables. Both of these variables are predefined in the IDE and point to specific set of jar files:

1. JRE System Library variable, which can be configured to point to any valid JRE. While you have the option to use the eclipse JRE that comes with the IDE, I recommend against it. The JRE System Library variable should point to WebSphere JRE because the code is ultimately going to run in WAS runtime environment.
2. WebSphere v5.1 runtime, which is added by WSAD or RAD when the project was created for WAS 5.x server. This variable includes all the J2EE and WebSphere libraries needed to build the project 

In any case you can follow these steps to move the project:

1. If the project doesn't exist in RAD already, import it using File > Import > Existing Project into Workspace, select the directory that contains the .project file and click Finish
2. Upon successful import, one or more of the following could happen:

• If you are using RAD and if you have installed WAS 5.x test environment, you should not get any errors. To use WAS 6.x runtime in this case,

1. Right click the project, select Properties > Java Build Path > Libraries tab
2. Select JRE System Library variable and click Edit button
3. Click Alternate JRE radio button, select WebSphere v6 JRE from the dropdown and click Finish
4. Go to the Server section in the Properties dialog box and select WebSphere Application Server v6.0 in the Target runtime dropdown
5. Click OK to close the Properties dialog box, the project should rebuild itself

• If you haven't installed WAS 5.x test environment, you will get errors upon importing a project that has WAS 5.x entries in its classpath. In that case,

1. Right click the project, select Properties > Java Build Path > Libraries tab
2. If the JRE System Library variable has an error, remove it
3. Click Add Library button, select JRE System Library click Next
4. Click Alternate JRE radio button, select WebSphere v6 JRE from the dropdown and click Finish
5. Remove the WebSphere v5.1 runtime entry
6. Go to the Server section in the Properties dialog box and select WebSphere Application Server v6.0 in the Target runtime dropdown
7. Click OK to close the Properties dialog box, the project should rebuild itself

If any of your projects had generated EJB code, you will get a number of compilation errors that won't make much sense, just delete all the generated code and do a clean build. If you will start using JDK 1.4 with this move and have assert statements in your code, there are some other considerations but I will write about that later.

WebSphere v6.1 is out for a while now. I recently got an opportunity to use it in the development environment and wanted to list my quick thoughts here:

• First off, there is no production release of Rational Application Developer (RAD) for WebSphere v6.1 yet. WAS 6.1 ships with a so called Application Server Toolkit (AST). In my personal opinion, toolkit is a misleading word as it makes customers think it's some sort of beta tool and not suitable for serious development. This perceived lack of development tools may even cause a delay in WAS 6.1 adoption. While I believe IBM should have released RAD 6.1 with WAS 6.1 (more on this in some other post), I also believe the toolkit has all the coding features an average development project needs. Some RAD features e.g. UML modeling are missing. If you are still not clear what AST offers, think of AST as WSAD for WAS 6.1
• Second, you cannot install the toolkit with WAS 6.1 test environment. You must install WAS 6.1 and toolkit separately and then point the toolkit to WAS 6.1 installation directory to use the server. I am not sure whether this is how RAD 7.0 (which is supposed to be the IDE for WAS 6.1) will work or RAD 7.0 will continue to have WAS install within its runtimes directory. Personally, I like the ability to use separate installation of WAS. This gives the flexibility to run the server outside the IDE and deploy and run applications on it.
• Third, the toolkit appears to support export and import of server profiles. Thank you IBM! In WSAD, an experienced developer could configure all the server parameters and distribute the server profile to the rest of the team. In RAD, this feature disappeared forcing every developer to go through the painful steps of configuring the server. But, looks like now this feature is back. At least it's back in the toolkit. I haven't personally used it yet (may be I will use it next week)
• Forth, Since I am using a separate server installation, I have to rely on the log files created within the server. In other words, not everything is printed on the old friend console within the IDE. This may not be true for RAD 7.0 but it's true for the toolkit. Also, if you are using WAS 5.x, the log files are at <app_server_home>/logs/<server_name>/<log_file_name>.log but WAS 6.x uses the concept of cell, node and profile. The new location for the log files is, <app_server_home>/profiles/<profile_name>/logs/<server_name>/<log_file_name>.log

Listed above are all the WAS 6.1/toolkit features related observations. Here are some miscellaneous observations. It's possible that some of these were implemented in WAS 6.0; consequently, the list below is more useful to some one migrating from WAS 5.x:

• By default WAS 6.1 installs as a windows service. I wish I could choose against it
• Security on WAS installation is turned on by default
• Default urls have changed as follows:
• Admin console is available on http://<hostname>:9061/ibm/console
• Applications are deployed on http://<hostname>:9081/<web_app>
• Universal Test Client is available on http://<hostname>:9081/UTC
• Server startup takes longer. It appears that the server initializes some out of the box applications. I have yet to dig into this

I absolutely love the format and formatKey attributes of bean:write tag in Struts framework. You can use these attributes to format the display of your form bean properties. This works pretty well in displaying currency and date/time values. For example, you can display 1234.567 as $1,234.57 and 08/12/2006 as Aug 12, 2006. Here is how it works:

<bean:write name="myForm" property="amount" format="$#,000.00" />

OR

<bean:write name="myForm" property="amount" formatKey="myapp.currency.format" />

AND

myapp.currency.format=$#,000.00 (in resource bundle)

The preferred way is to use the second format because it makes the code portable. Plus, if you want to change the format, you can make the change in resource bundle without having to worry about changing all your JSPs.

So far so good. When I tried to use this feature in one of my recent projects, it didn't work! Why? Because the type of the property being formatted cannot be String. The format attribute simply uses default format (display the property as is) when the property is of type java.lang.String. In other words,

private double amount; // will be formatted correctly

private String amount; // will NOT be formatted at all

This could be a feature or a limitation but I haven't been able to figure out why String shouldn't work! Why do I expect the format attribute to do the type conversion? Because the framework automatically does the type conversion on form submission. Here is what I mean by that:

// action form code

public class MyForm extends ActionForm{

private double amount;

}

// jsp code

<html:text name="myForm" property="amount" />

Even though request.getParameter("amount") returns a String, the framework happily converts the String to double. If this conversion is automatic, why can't it convert String to double and try to display the value in currency format in the format attribute? I am sure this has been raised/discussed/considered somewhere but I can't find it. If some one knows let me know.

There is another problem (not really a Struts problem though). There is no way to format phone numbers. If you get a String 8001234567 from the database and would like to convert to (800) 123-4567 OR 800-123-4567, currently there is no tag or attribute to do that (or I don't know about it). I was hoping, since it's so easy to format currency and date objects, it would be easy to format phone numbers but looks like it's my challenge to write something like that.