Known problems and limitations for WebSphere Application Server Developer Tools for Eclipse, Version 8.5.5
WebSphere® Developer Tools has limitations that are specific to particular programming models, server tools limitations, and general limitations.
- Limitations that are specific to particular programming models:
- Known problems and limitations for EJB applications
- Known problems and limitations for JPA applications
- Known problems and limitations for web service applications
- Known problems and limitations for SIP applications
- Known problems and limitations for OSGi applications
- Known problems and limitations for Apache Maven applications
- Known problems and limitations for web applications
- Server tools limitations:
- General limitations:
- WebSphere Developer Tools might not start correctly on some older Linux platforms
- Limitation when you use a loopback address
- A publishing operation can stall when the tools miss notifications from the server
- Changes to method annotations are not automatically updated in debug mode
- Limitation for web projects created by using WebSphere Application Server Developer Tools for Eclipse V8.5.5.Next Alpha (February update)
- When you select the facet levels for a project, the Details messages might indicate that a related facet level is required when it is only recommended
- When you change a project facet from CDI 1.2 to CDI 1.1, you must generate the beans.xml file manually
WebSphere Developer Tools might not start correctly on some older Linux platforms
On some older Linux platforms, such as RHEL 4, or SLES 10.4, the product might not start correctly. Shortly after choosing a workspace location, the product will fail with a generic error message. If you inspect the java core file, you see a General Protection Fault in the module: /lib/libc.so.6.
NULL ------------------------------------------------------------------------
0SECTION TITLE subcomponent dump routine
NULL ===============================
1TISIGINFO Dump Event "gpf" (00002000) received
1TIDATETIME Date: 2012/11/16 at 15:14:57
1TIFILENAME Javacore filename: /root/javacore.20121116.151456.12391.0002.txt
1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt)
1TIPREPSTATE Prep State: 0x0
1TIPREPINFO Exclusive VM access not taken: data may not be consistent across javacore sections
NULL ------------------------------------------------------------------------
0SECTION GPINFO subcomponent dump routine
NULL ================================
2XHOSLEVEL OS Level : Linux 2.6.16.60-0.85.1-bigsmp
2XHCPUS Processors -
3XHCPUARCH Architecture : x86
3XHNUMCPUS How Many : 2
3XHNUMASUP NUMA is either not supported or has been disabled by user
NULL
1XHEXCPCODE J9Generic_Signal_Number: 00000004
1XHEXCPCODE Signal_Number: 0000000B
1XHEXCPCODE Error_Value: 00000000
1XHEXCPCODE Signal_Code: 00000001
1XHEXCPCODE Handler1: B758949B
1XHEXCPCODE Handler2: B755E915
1XHEXCPCODE InaccessibleAddress: 00000000
NULL
1XHEXCPMODULE Module: /lib/libc.so.6
1XHEXCPMODULE Module_base_address: B7634000
1XHEXCPMODULE Symbol: memmove
1XHEXCPMODULE Symbol_address: B769F470
You can work around the problem with the following steps:
- Edit (or create) the workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.e4.ui.css.swt.theme.prefs file.
- Add the preference to enable the classic theme by adding the following
lines:
eclipse.preferences.version=1 themeid=org.eclipse.e4.ui.css.theme.e4_classic
Limitation when you use a loopback address
Loopback addresses resolve as remotehost when they are used for the first time in WebSphere Developer Tools, but they resolve as localhost in all subsequent attempts. As a result, if you are using a loopback address for the first time when you create a server, the tools resolve it as remotehost, and the remote server wizard is displayed. However, if you specify the same loopback address again to create a server, it resolves as localhost, and then the wizard to create a local server is displayed.
The most common loopback address is 127.0.0.1. However, the range is 127.0.0.1 through 127.255.255.255.
A publishing operation can stall when the tools miss notifications 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.
You can work around this problem. In the Console view, you will see a log message for the application you published. When the update has completed, you should see an application updated message for this application. This indicates that the server has completed the work. You can cancel the progress monitor in the Progress view and proceed normally.
Changes to method annotations are not automatically updated in debug mode
In a Liberty server, changes to method annotations are not automatically updated in debug mode.
See The hot method replace of debugging for a WebSphere Application Server for more information about this limitation.
WebSphere Developer Tools does not always support Java 1.8
WebSphere Application Server
classic, when used with WebSphere Developer Tools, does
not support Java 1.8 for all connection types. However, the WebSphere Developer Tools product supports Java 1.8 for all connection types.
- For Remote Method Invocation (RMI) connections, WebSphere Application Server does not support Java 1.8. Run Eclipse by using Java 1.6 or Java 1.7.
- For Interprocess Communications (IPC) connections, you can run Eclipse by using Java 1.6, 1.7, or 1.8, since WebSphere Application Server supports Java 1.8 by default.
- For Simple Object Access Protocol (SOAP) connections, WebSphere Application server supports Java 1.6 and 1.7. It also supports Java 1.8 if you follow the steps in the Resolving the problem section of Updating published application results in a SSLHandshakeException error when using a non-IBM JVM. You can run Eclipse by using Java. 1.8 if you follow the steps. Otherwise, run Eclipse by using Java 1.6 or 1.7.
When you select the facet levels for a project, the Details messages might indicate that a related facet level is required when it is only recommended
When you change a project facet level, the Details messages indicate when a related facet level is required for the facet. In some cases, this facet level is recommended, not required, even though the Details messages indicate that it is a required facet level.
When you change a project facet from CDI 1.2 to CDI 1.1, you must generate the beans.xml file manually
When you change a project facet from CDI 1.2 to CDI 1.1, the tools do not generate a beans.xml file. The list of errors in the Markers view does not include a warning about the missing beans.xml file.
You can work around this problem by generating a beans.xml file manually. To generate a beans.xml file, complete the following steps:
- Right-click on your project.
- Select .