© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.
The Minimize application files copied to the server option is supported by WebSphere® Application Server 6.0.2.5 and later. In the WebSphere Application Server V6.0 server editor, there is a check box for the option; the option is ignored if it is selected for server prior to version 6.0.2.5.
If an Enterprise JavaBean (EJB) module is shared among multiple EAR projects running on a WebSphere Application Server and one of the EAR project is removed from the server, other EAR projects must be restarted before they can access the resources, such as EJB beans, in the EJB project.
If you do not take this action, you might see error messages similar to those shown below. These errors happen because Java Naming and Directory Interface (JNDI) name in the EJB project are removed from the server when the EAR is removed.
Here is a sample error message:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: First component in name Session20Home not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
at ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
at ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
at ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Due to various behaviors and interactions between the Eclipse and WebSphere runtime environments, there are extra steps required when running multi-threaded WebSphere Application Clients through the Application Client Launch Configurations dialog box. The Application Client Launch Configurations dialog box is available from the J2EE perspective when you select Run > Run... in the toolbar of the product. If your client uses multiple threads, or uses frameworks that may use additional threads such as Swing, then you must complete the following additional steps:
- In the Application Client Launch Configurations dialog box, select the Arguments tab. Under the VM arguments text box specify the following parameter:
-Dosgi.noShutdown=true- Ensure your client application calls System.exit()
If these are not specified, you may see problems related to class loading or Java™ virtual machines (JVMs) that do not exit once the application has run to completion.
Suppose you have a project, for example an Application Client project, with the following configurations:
- the project facet for Java is set to version 1.4
- the target server runtime for this project has the hot method replacement option enabled in its server configuration
You may experience the Resume button in the Debug view does not work properly. For example, when you run the application on the server in debug mode, you attempt to change the source at runtime and then use the Resume button to continue debugging your application. You may experience your hot method replacement changes to the source code does not get applied.
Try clicking the Resume button twice to allow the runtime changes to take into effect.
Note: This problem does not occur when you set the project facet for Java to version 5.0.
The Remove button on the Manage Shared WebSphere Servers dialog box does not work correctly.
Tip: To open the Manage Shared WebSphere Servers dialog box:
- In the tool bar select Window > Preferences. The Preferences dialog box open.
- In the left pane, select Server > WebSphere > WebSphere v51.
- On the right pane, beside the Shared WebSphere servers field, click the Manage button. The Manage Shared WebSphere Servers dialog box opens.
If you use the Remove button, the server appears removed. However, if you exit the dialog box, open the dialog box again and refresh the remote server information, the previously removed server remains in the dialog box.
To workaround the issue you can manually remove the shared server entry by completing the following steps:
- Open the id.txt file which is located in the following directory:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
where <directory> is the installation directory of Agent Controller.- Delete the entry referencing the shared server you want to remove.
- Remove the WebSphere deployment directory that was specified for that particular shared server during server creation and all its subdirectories. Examples of subdirectories to remove under the WebSphere deployment directory are: config, installedApps, temp, and any other directories and files that reside under this directory.
- In the Manage Shared WebSphere Servers dialog box, specify a host name and click the Refresh button to verify you successfully removed the shared server.
If you have additional servers, such as IBM HTTP Server, installed within the same WebSphere Application Server v6.x profile, the WebSphere Server Settings page of the New Server wizard might not locate the correct remote method invocation (RMI) or SOAP port numbers. In addition, the port number for the administrative console might not be retrieved.
When the New Server wizard cannot locate the actual port numbers defined for a server, its default behavior is to pre-fill the port fields with the default port numbers: 2809 for RMI and 8880 for SOAP.
In the case when the incorrect port numbers are defined, you might experience the following problems:
- Cannot connect to the new server, such as cannot start or stop the server.
- Cannot open the administrative console from this new server, as a result may receive an administrative console port not defined error.
- Cannot run applications on this server, such as the Run on servers command does not work
Workaround:
- Determine the port values of a configured profile by referencing its server configuration files. The port values are stored in the serverindex.xml file located in the following directory:
<directory>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>, where <directory> is the installation directory of WebSphere Application Server.
Use the serverindex.xml file to fill-out the below table to determine the actual port numbers defined for your server:
Port name Port description Default port number Your assigned port number SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Administrative Console 9060 WC_defaulthost HTTP transport 9080 - To connect to the server, specify the correct RMI or SOAP port number when you create the server.
- To start the administrative console, use an external Web browser and type in the address field the URL to the correct administrative console port:
http://<machine_name>:<WC_adminhost>/IBM/console
For example: http://localhost:9060/IBM/console- To run applications on the server, issue a Run on server command. When the Web browser opens, correct the URL with the HTTP transport port number defined for your server.
http://<machine_name>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
For example: http://localhost:9080/MyApplication/index.jsp
Note: The servers automatically defined in the Servers view might not reference the correct port numbers to the actual server. If this is the case, use the same above workaround.
The Profile Management tool is a WebSphere Application Server tool which creates the profile for each runtime environment. You can use the workbench to start WebSphere Application Server's Profile Management tool. However, the Profile Management tool does not work under a 64 bit processor, instead use the manageprofiles command line tool provided by WebSphere Application Server.
On Windows operating systems, if you are using the remote method invocation (RMI) port to connect to your WebSphere Application Server v6.x, you might experience long delays establishing a connection to the server after losing network connectivity. This can occur even if the server is local and the network connectivity is lost only temporarily, which is common in a wireless network environment.
If you know the server is started, but the status in the Servers views displays Stopped or Starting, try to see if you can establish a connection to the server by switching the server connection from RMI to SOAP. The status of the server should change to Started.There are a couple of options that are available to establish connection to a server in a wireless network environment:
- The easiest and safest option, is to switch your connection to use the SOAP port. After losing network connectivity, SOAP connections have the ability to recover more quickly compared to a RMI connection.
- If you must use a RMI connection, you can try to modify the default settings pertaining to the Domain Name System (DNS) caching on the Windows operating system. For details, refer to the following Microsoft support article:
http://support.microsoft.com/kb/318803
Windows operating system has a built in DNS caching that maintains resolved host names. This allows for a faster turnaround when issuing DNS lookups. However there is a disadvantage to this, which is if a DNS lookup fails. The Windows operating system caches the failed value, for a default time of 300 seconds. So even if the DNS server can resolve the lookup shortly thereafter, it does not actually attempt the lookup until the cache time expires. As a result, a failed DNS lookup with default settings can take as long as 5 minutes before a true retry is attempted in the lookup. Setting the cache time to 0 seconds forces the Windows operating system to never cache failed DNS lookup queries, and allow the reconnect to occur as soon as the DNS becomes available.
The following is an example of disabling DNS caching for failed lookups on Windows operating systems:
In the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Add one of the following registry value:
- For Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- For Windows 2000:
"NegativeCacheTime"=dword:00000000
Republishing the application, restarting the application, or uninstalling and reinstalling the application are not sufficient actions to apply a variety of resource changes defined in the Deployment page of the Application Deployment Descriptor editor onto the server. A change to the database name of a data source in the Deployment page of the editor is a known change that the server cannot pick up, there might be several other changes the server cannot pick up.
As a workaround, complete the following steps to apply the changes onto the server:
- Stop the server.
- In the Servers view, right-click the server and select Stop.
- In the Servers view, wait for the status of the server to display Stopped and then continue to the next step.
- Start the workbench.
NOTE: If the server fails to start, you need to use the functions from your operating system to stop the java process on which the server is running. Alternatively, you can restart the workbench and then try to start the server again.- Start the server.
- In the Servers view, right-click the server and select Start.
- In the Servers view, wait for the republish to complete and the status of the server and application to display Started and then continue to the next step.
- Run your application on the server, for example use the Run on Server command. As a result, the server should now be able to pick up the changes from the Application Deployment Descriptor editor.
If you add a utility JAR file to Web Libraries for a Web project and refer to classes inside the JAR file in your code, you might get a java.lang.NoClassDefFoundError error when you try to run the application on the server.
The workaround is after adding a utility JAR file to the EAR module, then add the JAR file to the J2EE Modules dependencies of the Web project, by completing the following steps:
- Add a utility JAR file to the EAR module. See the Adding project utility JAR files topic in the product help for details.
- Right-click on your Web project and select Properties. The Properties dialog box opens.
- Select J2EE Modules Dependencies.
- In the J2EE Modules tab under the JAR/Module column, select the check box beside your utility JAR file.
If a WebSphere Application Server V6.1 is running on a secured SOAP connection, another secure SOAP connection to a WebSphere Application Server V6.0 is going to fail. The same problem occurs in the converse order, such as a WebSphere Application Server V6.0 running on a secured SOAP connection causes a secure SOAP connection to a WebSphere Application Server V6.1 to fail. However, the problem does not occur if the server is defined in the Servers view and its status is blank.
The workaround is to use a secure remote method invocation (RMI) connection to the server instead of SOAP connection, or use a non-secure SOAP connection.
If the remote server is stopped, the New Server wizard may take a long time to complete after you click the Finish button. A workaround is to start the remote server before you click the Finish button in the New Server wizard.
If a file with a .war extension is placed in the EarContent folder of an EAR project and it is not defined as a Web module in the application.xml, the enterprise application fails to publish on the server with the following sample error message:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Could not open the nested archive "abc.war" in "D:\myworkspace\PublishEAR\EarContent"The cause of this error is the workbench cannot handle the file correctly as a Web module. Choose one of the following workarounds:
- If the file is a Web module, add the file as a module to the enterprise application. For details, see Adding modules to an enterprise application topic in the product help.
- If the file is not a Web module, a suggestion to workaround the publishing problem is change the file extension to another extension other than .war, for example to .jar
For a remote WebSphere Application Server V5.1 or a remote WebSphere Application Server V5.1 Express edition, if you change the deployment directory and publishing directory in the server editor and then republish the application, the application continues publishing to the previous destination. As a result, your changes in the publishing and deployment directories are not applied. This problem occurs when using either local copy or FTP methods.
The workaround is restart the workbench. As a result, the configuration changes for the publishing directory and the deployment directory should take into effect.
To support a more flexible approach for storing projects, the technique for publishing applications has changed. Applications are now copied before they are published to the server. If your application is large, for example greater than 100 megabytes, this copy operation used for the publish command is going to take additional time as opposed to what you have experienced in the previous version.
Currently, there is no workaround. IBM is working on an update that will eliminate the need to perform this new copy operation for most cases.
If a secured WebSphere Application Server v6.1 is started and in the server editor you change the server connection type to either remote method invocation (RMI) or SOAP, you might see the following publish fail error message after you save the changes in the server editor:
Publish is not performed since the server is not started. Start the server before performing the publish operation.
You can safely ignore the error. Optionally, after the status of the server in the Servers view is Started, you can complete a publish command (in the Servers view, right-click the server and select Publish).
When you try to generate a data source using the Table and Data Source Creator wizard, you may encounter a TargetInvocationException error in the Details section of the Table and Data Source Creations Results dialog box.
The cause of the TargetInvocationException error might occur if you import a project interchange that contains data sources defined with same Java Naming and Directory Interface (JNDI) name.
To workaround the TargetInvocationException error, verify if a data source with the same JNDI name is already defined in the workbench. If so, remove it from the Deployment page of the Application Deployment Descriptor editor and then create the data source again using a different JNDI name. The JNDI name needs to be unique as it is a naming and lookup service that is used to bind an enterprise bean to a data source.
When stopping the server from the Servers View, the server might not completely stop. The Servers View displays as Stopped but the server process might be in a non-responsive state. This usually occurs when artifacts such as your application or the workbench remains holding onto references to classes on the server. The following are example scenarios:
- Applications that are in endless loops, or application hold on references to some classes on the server
- Applications that make Cloudscape or Derby database connection without cleaning up their connection
- Using the Test Connection button in the New Connection wizard of the data tools to open a connection to a Cloudscape or Derby database without disconnecting from the database
Restriction: Multiple connections to a single Cloudscape or Derby database are not supported due to a Cloudscape or Derby configuration restriction. If you maintain the database connection to the database from the Database Explorer and a server tries to make another Cloudscape or Derby connection through a data source, the second connection is going to fail. As a result, you need to close the connection from the Database Explorer before a server can establish a connection to the Cloudscape or Derby database.
To workaround the problem, you to need use the functions from your operating system to stop the java process on which the server is running. Alternatively, you can restart the workbench to force the reference to be released. The last example scenario described in the third bullet, you can use the Database Explorer view to connect and then disconnect from the Cloudscape or Derby database connection.
It is possible that when you are publishing resources to the server, for example an enterprise bean, and you use the Universal Test Client (UTC) for testing an EJB, the JAR file gets locked and cannot be updated. This results in changes made in the tooling not being picked up during the testing of the EJB. Once the UTC loads the EJB JAR file, the JAR file remains locked until the application is removed and re-added, or the server is restarted.
The workaround is to use the UTC in the development environment where the resources of the application are running out of the workspace, and not run on the server. This can be configured using the New Server wizard, or changed later by using the server editor by selecting Run sever with resources within the workspace under the Publishing options. This allows individual files within the EJB project to be updated without requiring a full replacement of the entire EJB JAR file.
Once the application has been fully tested it can be published to the server using the Run server with resources on Server publishing option.