Test and deployment tools - release notes

1.0 Introduction
2.0 Supported software and specifications
3.0 Changes from the previous release
4.0 Known problems and limitations
   4.1 WebSphere Application Server may not start due to invalid characters
   4.2 Starting the remote WebSphere Application Server using RAC
   4.3 Long directory names can cause errors in JSP testing
   4.4 Internet Explorer: disable proxy or socks server when using local addresses
   4.5 Problems using Apache Tomcat when disconnected from the Internet
   4.6 Considerations for running servers in debug mode
   4.7 WebSphere server security
   4.8 Running Java applications that connect to WebSphere Application Server
   4.9 Running WebSphere V4.0 Administrative Client with security enabled
   4.10 WebSphere Test Environment versions
   4.11 Using constructors in the Universal Test Client
   4.12 Setting backend ID when using the auto table and data source creator
   4.13 Case sensitivity problem when publishing remote V5 server on Windows
   4.14 Default JNDI Provider URL in the Universal Test Client
   4.15 J2EE client cannot access test environment server on a remote machine
   4.16 Tracing with WebSphere version 4.0
   4.17 Problems with plug-ins in the Internal Web browser
   4.18 Cannot Test EJB 2.0 Local Relationships in the Universal Test Client
   4.19 WebSphere V5.0 Security Settings
   4.20 Removing child projects from an EAR project that is defined in a server configuration
   4.21 Some files are left behind after uninstalling WebSphere V4 runtime
   4.22 National language problems
   4.23 Add extra paths to the environment variable java.library.path to WebSphere servers
   4.24 Limitations of the MQ simulator
   4.25 Error message when stopping a V5 WebSphere server
   4.26 Message when applying WebSphere V4 PTF

1.0 Introduction

The Server Tools feature enables you to test and publish J2EE applications on different local and remote run-time environments. This readme file describes limitations, known problems, and workarounds that are associated with the following Server Tools functions:

The online help for testing and publishing contains additional information on Server Tools restrictions and on working around problems in Server Tools.

For information on supported run-time environments refer to the product readme.

2.0 Supported software and specifications

The Universal Test Client requires the use of Netscape Version 6.0 or higher or Microsoft Internet Explorer 5.0 or higher

3.0 Changes from the previous release

4.0 Known problems and limitations

4.1 WebSphere Application Server may not start due to invalid characters

If you install WebSphere Studio into a directory whose name contains a dollar sign ($) or any odd character, the WebSphere test environment will not work. To avoid this, do not install WebSphere Studio into a directory containing a $ character.

4.2 Starting the remote WebSphere Application Server using RAC

When debugging remotely or deploying to WebSphere Application Server Version 5.0, ensure the server has fully stopped before restarting. If it has not, you may see the following message and need to start the server again:

IWAD0251E An error occurred when starting the server: IWAD0250E Ensure that the remote Agent Controller is started in the remote server machine and the WebSphere installation directory is correct. Ensure that the WAS_HOME_V5 variable is set to the correct WebSphere installation directory on the remote Agent Controller.

4.3 Long directory names can cause errors in JSP testing

If you install WebSphere Studio in a directory with a long path or choose long names for your Enterprise Application project or Web project, you may get the following error message when trying to execute a JSP page:

Error Message: JSPG0113E: JSP file
"Xxx/Yyy_jsp_0.java (Filename too long)" not found

If you receive this error, you may take any of the following actions:

4.4 Internet Explorer: disable proxy or socks server when using local addresses

If you are using a proxy or socks server in Internet Explorer, it should be disabled for local addresses. Otherwise, this may cause problems when trying to view the Universal Test Client or any other Web applications when using either the internal Web browser or your installed version of Microsoft Internet Explorer.

4.5 Problems using Apache Tomcat when disconnected from the Internet

The default web.xml file that ships with Apache Tomcat contains a reference to a DTD file on the Internet. Due to this, Tomcat servers will not start when disconnected from the Internet. In WebSphere Studio, these references have been removed from the Tomcat version 3.2 configuration so that you may work while running standalone. If you import a Tomcat server configuration from outside WebSphere Studio or are using Tomcat version 4.0, you may have problems working while disconnected from the Internet. If this occurs, take the following steps to remove this reference.

  1. Backup the web.xml file from your Tomcat server configuration.
  2. Edit the web.xml file in your Tomcat server configuration using a text editor.
  3. Remove the entire DOCTYPE element from the file.
  4. Save and close the editor.
If you have problems when starting the server, you may need to connect to the Internet and re-add the DOCTYPE element using the backup web.xml file.

4.6 Considerations for running servers in debug mode

Consider the following when deciding to run a server in debug mode.

4.7 WebSphere server security

When enabling security for a server, do not give it a server ID that has the same name as the machine where WebSphere Application Server is installed. Otherwise, WebSphere Application Server may fail to start.

The User Rights policy for the server user ID must also grant the user the privilege of Act as part of the operating system.

4.8 Running Java applications that connect to WebSphere Application Server

WebSphere Application Server has a restriction that all Java applications that use the WebSphere client to connect to enterprise beans running on a WebSphere server must use the same level of the IBM Java ORB that was used to build the WebSphere client. If you do not use the same ORB level, you may receive an error like the following when running the client application:

java.lang.NoClassDefFoundError: com/ibm/rmi/iiop/GIOPVersionException

To ensure that the correct ORB level is used, you can run the client application using the WebSphere JRE. To do this, take the following steps:

  1. Open the Launch Configurations dialog using the Run > Run or Run > Debug menu items in the Debug perspective.
  2. Select the Java Application Launch Configuration that you want to edit.
  3. Go to the JRE page and select the appropriate WebSphere JRE from the combo box.
  4. Apply the changes.

Alternatively, you can run the client application with any JRE as long as you ensure that the matching ORB level is used. To do this, take the following steps:

  1. Open the Launch Configurations dialog using the Run > Run or Run > Debug menu items in the Debug perspective.
  2. Select the Java Application Launch Configuration that you want to edit.
  3. Go to the Arguments page and add the following to the VM Arguments field:
    -Xbootclasspath/p:WAS_installdir\java\jre\lib\ext\ibmorb.jar
    where WAS_installdir is the directory containing the runtime, e.g., c:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4
  4. Apply the changes.

4.9 Running WebSphere V4.0 Administrative Client with security enabled

The WebSphere version 4 administrative client cannot be launched directly from the workbench when security is enabled. To launch the administrative client follow these steps:

  1. Start the WebSphere server.
  2. Open a Web browser and enter the following URL: http://[localhost:8080]/admin, where [localhost:8080] is the server name and port that you are using.
  3. Enter the userid and password you used to configure the security. Click Submit.
  4. In the right hand pane, click Configuration > Open.
  5. Select "Enter full path to file on server".
  6. Enter the full path to your server configuration in the text field. For example: C:\studio\eclipse\workspace\Servers\was.wsc\server-cfg.xml.
  7. Click OK.

4.10 WebSphere Test Environment versions

The WebSphere version 4 test environment is based on WebSphere version 4.04. The WebSphere version 5 test environment is based on WebSphere version 5.0. When you migrate from a previous version of WebSphere Studio, any e-fixes to the WebSphere test environment will be removed and you must reinstall them manually.

4.11 Using constructors in the Universal Test Client

When using the Universal Test Client you will be unable to construct objects that take interfaces as parameters in the parameter page. All objects to be constructed from parameters with interface types must use the class references section.

First load and construct an object of the interface or abstract type. Then load your class that contains the constructor with the abstract/interface type. Now choose the premade object in the parameters page.

4.12 Setting backend ID when using the auto table and data source creator

When using the auto table and data source creator to unit test CMP enterprise beans, you must set the backend ID to Cloudscape. By default, the current backend ID is empty, but at run time it will use DB2 as a backend ID, unless you explicitly specify an ID.

To specify Cloudscape as the backend ID, do the following:

  1. In the J2EE Hierarchy view, right-click the EJB project and select Open with > Deployment Descriptor Editor.
  2. Scroll down to the Backend ID section.
  3. Click the Refresh button beside the Current field, to load all the available backend ids.
  4. In the Current field, select the Cloudscape map you generated from the drop-down menu. For example, CLOUDSCAPE_V50_1.
  5. Save your changes and close the editor.

4.13 Case sensitivity problem when publishing remote V5 server on Windows

If a project has been published to a remote V5 server on Windows, and then the project is renamed to the same name but with different cases, e.g. rename "MyEarProject" to "myearproject", you may get some File does not exist errors during server startup. This is a limitation on Windows that WebSphere Studio cannot distinguish between the two published projects with the same name of different cases. The problem can be fixed by manually removing the published server configuration from the remote machine and then republishing the project.

4.14 Default JNDI Provider URL in the Universal Test Client

The default JNDI provider URL for the Universal Test Client has been changed from WebSphere Studio version 4.0. The new provider URL is "iiop://2809" instead of "iiop://900". If you are launching the test client manually and require the old port number (e.g. to access WebSphere v4.0), you can change the provider URL via the Properties page within the test client.

4.15 J2EE client cannot access test environment server on a remote machine

You may get an org.omg.CORBA.COMM_FAILURE when trying to access a test environment server from a J2EE client running on a remote machine. You have to configure the ORB bootstrap host name defined in the remote server configuration to fix the problem. To edit the ORB bootstrap host name, go the Ports page of the server editor and set the Host name field under the ORB bootstrap port section to the remote host name .

After the change is made, save the changes and restart the test environment server for the changes to take place.

4.16 Tracing with WebSphere version 4.0

If you disable tracing for WebSphere version 4.0, you will get a ConnectionException in the console and will be unable to stop the server correctly.

4.17 Problems with plug-ins in the Internal Web browser

The internal Web browser cannot be used to test Web pages containing plug-ins to the Internet Explorer browser. Browsing to a page containing plug-ins may cause the IDE to crash. To avoid this problem, set the preference to use an external Web browser when testing pages that may contain plug-ins.

4.18 Cannot Test EJB 2.0 Local Relationships in the Universal Test Client

The Universal Test Client does not support transactions across multiple requests. This means that EJB 2.0 local relationships cannot be tested because you cannot get the collection containing the relationship, and work with the contents in a single request.

4.19 WebSphere V5.0 Security Settings

The "Local OS Authentication" label on the Security page of the WebSphere v5.0 server configuration editor is incorrect. The Server ID and Server password fields will update the currently enabled security mechanism, regardless of which type of authentication.

4.20 Removing child projects from an EAR project that is defined in a server configuration

After a child project, for example a Web project, has been removed from an EAR project that is defined in a server configuration, a dialog box will prompt you to make the corresponding changes to the server configuration. However, the child project will not properly get removed from the server configuration even if you choose to fix it in the dialog box. To fully remove a child project from the server configuration, open up the server editor and a dialog box will prompt you to automatically fix the project definition. Click OK and save the editor for the changes to take place.

4.21 Some files are left behind after uninstalling WebSphere V4 runtime

When the WebSphere V4 runtime is uninstalled, the directory /runtimes/aes_v4 may still exist after the uninstall. You have to manually remove this directory if the directory still exists; otherwise, you may get some problems in the WebSphere V4 server support. The same check needs to be done manually if WebSphere Studio is uninstalled and then installed on the same location again.

4.22 National language problems

You cannot use a national language name for a WebSphere v5.0 configuration. If you do, the name will appear corrupted. When using a remote WebSphere server, a garbled message will appear in the console if the remote Agent Controller is not started or cannot be accessed on the remote machine. Verify that the remote Agent Controller is configured and running correctly on the remote machine.

4.23 Add extra paths to the environment variable java.library.path to WebSphere servers

The WebSphere server requires some paths to be set to the java.library.path system property in order to start the server properly. If you want to add extra paths to the environment variable java.library.path to a WebSphere server, you have to add a system property with the key java.library.path on the Environment page of the server editor.

For WebSphere V5 servers, set the value to ${WAS_INSTALL_ROOT}/bin;${WAS_INSTALL_ROOT}/jre/bin; extra_paths for a test environment server or a remote server

where extra_paths are the paths that you want to add to the java.library.path system property.

For WebSphere V4 servers, set the value to WebSphere_runtime_path/bin; extra_paths

whereextra_pathsare the paths that you want to add to the java.library.path system property

WebSphere_runtime_path is the WebSphere runtime path. In a remote server, this path will be the absolute path of the WebSphere installation seeing from the remote server, e.g. C:/WebSphere/AppServer. In a test environment server, this path will be WS_installdir/runtimes/aes_v4/bin where WS_installdir is the installation path of WebSphere Studio.

4.24 Limitations of the MQ simulator

When using WebSphere MQJD, only in-process applications can make use of this feature. Persistence is not supported.

4.25 Error message when stopping a V5 WebSphere server

When stopping a V5 WebSphere server, you may see the following error message on the system output:
"The XML Parser does not support disabling DOCTYPE declarations. This server will be vulnerable to Denial-of-Service attacks."
You can safely ignore this message.

4.26 Message when applying WebSphere V4 PTF

When applying the WebSphere V4 PTF, you may see the message "NOTE: Please regenerate the plugin configuration once the server is started in order to update the plugin-cfg.xml file". You can safely ignore this message.

Return to the main readme file