General workbench issues
Effectively manage your servers and the workbench by reviewing associated issues. Issues include, among others, servers not stopping from the Servers view, limitations of servers due to invalid characters, and workspace migration issues.
- Troubleshooting if a problem is related to the workbench or the application server
If you encounter errors or problems when you are running your application on the server by using the development workbench, try reproducing the problem by using only the tools that are provided by the application server without the use of the development workbench. For example, to reproduce the problem on WebSphere® Application Server, try installing and publishing the enterprise (EAR) application by using only the administrative console, see the Installing enterprise application files with the console topic available in the information center for WebSphere Application Server. - Limitations of servers due to invalid characters
If you install this product into a directory whose name contains a dollar sign ($) or any odd character such as #, %, +, or *, the server might not be created or might not start. To avoid an unsuccessful startup, do not install this product into a directory that contains any of these characters. - Limitations of server target validation
- Limitation of WebSphere Application Servers when workspace path begins with a backslash
WebSphere servers might not start when you use a workspace that begins with a backslash, for example \workspace or \myworkspaces\work1 - Limitation on the workbench to work with a WebSphere Application Server that changed its host name
- Limitations of servers due to long directory names
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 might get errors when you start a server, or when testing files on a server. - The server might not stop completely when stopping the server from the Servers view
When you stop 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. The non-responsive state 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: - A timeout error displays when starting the server immediately after a stop request is issued
Starting a WebSphere Application Server immediately after a stop request is issued can result in a timeout error message; even if the status of the server in the Servers view displayed Stopped before you starting the server. - Limitations of X on Linux when you are using the WebSphere Application Server
It is a known problem that when you use the X GUI on Linux when you are using WebSphere Application Server, you might get the following error, which prevents the Run dialog box from appearing: - A runtime problem occurs when a Web 2.4 project requests EJB 3.0 injections
If a servlet is contained in a web 2.4 project and is requesting EJB 3.0 injections, a runtime error in WebSphere Application Server v7.0 results. An example of a runtime error that can be produced is a null pointer error that is produced from a doGet or doPost method. - Workspace migration limitation
If you have a WebSphere Application Server V8.5 run time that is installed in your workspace that uses Java™ 6, and you import a project that was created with a WebSphere Application Server V8.5 run time that uses Java 7, the migration wizard fails because the installed WebSphere Application Server V8.5 run time does not support Java version 7. - Web project wizard limitation
If you install a WebSphere Application Server V8.5 run time in your workspace that uses Java 6, and then change the JRE version of your WebSphere Application Server V8.5 run time to v 1.7. after you create a web project, when you create a second web project, it will use the JRE 1.6 facet.
Parent topic: Limitations and troubleshooting tips for Server tools

