Developer Tools known restrictions
Several known restrictions apply when we are working with the WebSphere Application Server Developer Tools for Eclipse.
See also Runtime environment known restrictions.
List of known issues and restrictions:
- EJB 3.1 restrictions
- Projects required by web fragment projects are not automatically added to the Java build path
- Unable to interact with the Liberty profile server after modifying the console log level settings
- Copy and pasting servers might cause the publishing state to become out of synchronization
Unable to recognize the start of the server when the hideMessage attribute is used to suppress the messages
Unable to import WAR file with no web.xml deployment descriptor and with Liberty profile server configured with JRE version 6 or below as target runtime
Unable to import EJB jar file with no ejb-jar.xml deployment descriptor and with Liberty profile server configured with JRE version 6 or below as target runtime
Remote Liberty profile server remains in Publishing state with the message "Waiting for application status from the server"
EJB 3.1 restrictions
The tooling provides support for developing applications that use the full EJB 3.1 API. However, applications deployed on the Liberty profile should use only features included in EJB 3.1 Lite, which is a subset of the full specification. Applications deployed on the Liberty profile can also use features included in Message Driven Beans. See ejbLite-3.1 feature restrictions.
Projects required by web fragment projects are not automatically added to the Java build path
If we have a web application project containing one or more web fragment projects, and the web application project has references in its deployment assembly page to projects required by the web fragment projects, then those dependent projects (such as the JPA and Utility projects) are not automatically added to the Java build path of the web fragment projects.
Manually add the dependent projects to the Java build path of the web fragment projects in order for them to compile.
Unable to interact with the Liberty profile server after we modify the console log level settings
There is a known limitation when the console log level is set to WARNING, ERROR, or OFF. The workbench has problems when it interacts with the Liberty profile server, such as cannot start, stop, or publish to the server. For example, the workbench is unable to start the Liberty profile server and the following timeout error message displays:
The console log level (consoleLogLevel) is an attribute of the logging configuration element in the server configuration (server.xml) file with the following range options: INFO, AUDIT, WARNING, ERROR, and OFF. AUDIT is the default value for the console log level settings. For more details, search for the consoleLogLevel attribute in the Configuration elements in the server.xml topic. To work around this known limitation, specify INFO or use the default AUDIT setting for the console log level:
- In the Servers view, expand the Liberty Profile server.
- Right-click the Server Configuration[server.xml] node and select Open.
- In the Server Configuration editor and under the Configuration Structure section, expand Server Configuration node. The next step depends if the Logging element is available:
- If the Logging element is available, select it and under the Logging section of the server configuration editor, use the drop-down menu for the Console log level field, and select either the AUDIT or INFO option. Type Ctrl + s to save the changes in the editor.
- If the Logging element is not available, the workbench is already using the default AUDIT setting. As a result, we might be experiencing a different problem that is causing interaction failures between the workbench and the Liberty Profile server.
.
Copy and pasting servers might cause the publishing state to become out of synchronization
Try to avoid copying and pasting servers because they point to the same configuration file. Copying and pasting servers might cause the publishing state to become out of synchronization. For example, when you remove an application from one server, the application still appears to be deployed to the other server even though it is not. Server state will not synchronize up again until the next publish operation.
Unable to recognize the start of the server when the hideMessage attribute is used to suppress the messages
We can configure the <hideMessage> attribute in the Logging element of Server Configuration [server.xml] to suppress messages. If we configure to hide the server start message, for example <logging hideMessage="CWWKF0011I"/>, then the tool fails to recognize the state of the server when it is started. In such a situation, the state of the server in the Server view remains as starting until timeout and finally displays the following message:
Unable to import WAR file with no web.xml deployment descriptor and with Liberty profile server configured with JRE version 6 or below as target runtime
If we attempt to import a WAR file using the option File > Import > Web > WAR file, and the WAR file we select does not have a deployment descriptor, web.xml, and we select a Liberty profile server configured with a JRE version 6 or below as the target runtime, the OK button is not enabled, and no error is displayed in the wizard.
Unable to import EJB jar file with no ejb-jar.xml deployment descriptor and with Liberty profile server configured with JRE version 6 or below as target runtime
If we attempt to import a EJB jar file using the option File > Import > EJB > EJB JAR file, and the EJB jar file we select does not have a deployment descriptor, ejb-jar.xml, and we select a Liberty profile server configured with a JRE version 6 or below as the target runtime, the OK button is not enabled, and no error is displayed in the wizard.
Remote Liberty profile server remains in Publishing state with the message "Waiting for application status from the server"
When doing a Publish to push updates to an application, the operation stalls with a Waiting for application status from the server message. This is a situation where the developer tools miss notifications from the server. The Publish may be complete but because the tools do not receive the notification, the operation continues to wait.
In the Console view, we will see a log message for the application you published. When the update has completed, we should see an application updated message for this application. This indicates that the server has completed the work. We can cancel the progress monitor in the Progress view and proceed normally.
Parent topic: Troubleshooting tipsReference:
Runtime environment known restrictions Troubleshooting tips