This section describes known server tools limitations and problems along with their solutions.
If you are running a desktop firewall that blocks access to your system ports, you may receive warnings when starting servers, or the servers may simply fail to start. To work around the problem, you must give TCP/IP port access to the server process.
The Java Virtual Machine (JVM) caches the IP addresses of hosts so that it does not have to do a DNS lookup for the same node more than once. This leads to the development environment's incorrect identification of any host that changes its IP address for any reason as for example, when it is disconnected from the current network, and plugged into another one.
If you install this product into a directory whose name contains a dollar sign ($) or any odd character such as #, %, +, or *, the server may not be created or will not be started successfully.
If you use a workspace in a directory with a long path or choose long names for your Enterprise Application project or Web project, you may get errors when starting a server, or when testing files on a 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.
WebSphere servers may not start when using a workspace that begins with a backslash, for example \workspacea or \myworkspaces\work1.
If you are running servlets in single classloader mode in the WebSphere test environment, and you make changes to the servlets, the changes may not be reloaded. This is working as designed, as using single classloader mode is not a recommended J2EE practice.
When you target a project to one server type and run on a different server type (which may have incompatibilities with each other), you will not receive any errors during publish or startup.
The Servers view does not initially show a status or state.
When using the WebSphere v6.0 server tools on Linux, there might be some trace output in the console window that was used to launch the product.
The ${application} policy in the Java 2 policy security files (for example was.policy) applies only to the EAR project and will not affect the modules contained in the EAR.
On the console view, you might notice old console output that was generated from a previous run of a WebSphere Application Sever V6.0.
On Windows®, a restricted or standard user fails to start the server or run any tasks involving a started server.
If you change the target server for an EJB project and attempt to run the application on a server target that is different from its generated deployment code, the application fails to run. To fix this problem, you need to regenerate the deployment code. Right-click the EJB project, and select Deploy.