Known problems and limitations for WebSphere Application Server Developer Tools for Eclipse

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 fails 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:

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.

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.

Limitation for web projects created by using WebSphere Application Server Developer Tools for Eclipse V8.5.5.Next Alpha (February update)

If a new web project was created using the WebSphere Application Server Developer Tools for Eclipse V8.5.5.Next Alpha (February update), then the dynamic web module version would have been incorrectly set to 3.1. The tools would deploy these projects on the Liberty server even though it does not support version 3.1.

The tools have been fixed so that new projects have version 3.0 and version 3.1 applications cannot be deployed on the server. Projects that were created using the WebSphere Application Server Developer Tools for Eclipse V8.5.5.Next Alpha (February update) will need to be re-created.

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:

1. Right-click on your project.
2. Select Java EE tools > Create CDI Beans Deployment Descriptor Stub.

REST API definitions in OSGi applications are not supported on WebSphere Application Server traditional Version 9

The IBM® WebSphere Application Server Developer Tools for Eclipse wizards allow Representational State Transfer (REST) services and client code generation from swagger documents into Open Service Gateway Initiative (OSGi) bundles. However, deploying the OSGi application to WebSphere Application Server traditional Version 9 causes the publishing to hang.

This limitation applies to WebSphere Application Server traditional Version 9 only. Java Platform, Enterprise Edition web applications on WebSphere Application Server traditional Version 9 are supported. OSGi and Java Platform, Enterprise Edition web applications are supported on WebSphere Application Server Liberty.

A security certificate appears when your Docker container starts with the same port and a different container name.

If you set up each Docker container with a different certificate, you create the server with an identical host name and port in each workspace. The tools cannot differentiate between the containers. If you start another container with the same port, user name, and password, the tools prompt for a certificate. When you start a new container with the same port and host, you cannot check the container ID and container name before you connect to the Docker container.

Eclipse Auto-Generated URL Issue for Jakarta EE Projects (Java EE > 8)

When working with Jakarta EE projects (above Java EE version 8) in Eclipse, the IDE generates malformed URLs when using the "Run on Server" option from the servlet class. Although the application deploys successfully to the target server without errors, the automatically generated URL that Eclipse attempts to open in the browser is incorrectly formatted and will result in a "page not found" error. To access the deployed application, developers must manually construct and enter the correct URL in their browser using the standard format: http(s)://<ip-address>:<port>/<project-name>/<url-pattern>. The application functionality remains unaffected, and this workaround ensures proper testing and verification of the deployed servlet functionality.

Incompatible Web Facet Version Assignment for SIP 1.1 Projects with Liberty Runtime 25.0.0.12

When creating a SIP 1.1 project using WebSphere Developer Tools with Liberty runtime version 25.0.0.12, the project creation wizard assigns a Web facet version greater than 4.0 (specifically versions 5.0 or 6.0). This configuration is incompatible with the SIP 1.1 feature requirements, as documented in the Open Liberty Docs Overview, which specifies that the SIP 1.1 feature only enables servlet-3.1 and servlet-4.0 features. Consequently, the Dynamic Web Module facet version must be constrained to the range of 3.1 to 4.0 for proper compatibility. To resolve this issue, developers must manually adjust the project configuration by opening the Project Facets settings in Eclipse IDE, inspecting the Dynamic Web Module version, and manually setting it to version 4.0 if a higher version has been assigned during project creation.

Application Client Module Version Incompatibility in Enterprise Application Project Creation Wizard

When creating an Enterprise Application Project (EAP) using the creation wizard with the "new modules" option, the Application Client module is automatically generated with the latest supported facet version regardless of the selected EAP version. This may result in version incompatibility between the Application Client and the target EAP, preventing the generated modules from being properly attached to the resulting Enterprise Application.