2 posts tagged with "jakarta-ee"

We're thrilled to announce a significant milestone for our JEE platform. Support for Jakarta EE is now available! Our JEE platform expanders now target Java EE 7-8 or Jakarta EE 10.

Releases​

At this time, the full support for Jakarta EE is not yet available in beam releases. For migrating expanders and testing until the time that these releases make it into the beams, we've provided developer previews that mirror the beams, but contain the latest versions of all expansion resources.

Preparing your expander project​

Expander projects may require some updates if they expand code with javax imports. The first step would be to migrate those specific expanders to the new imports system.

When moving the imports to the mapping file, they should be redefined as the new jakarta imports. The imports as defined in the mapping should be considered the optional/default case:

<?xml version="1.0" encoding="UTF-8" ?>
<mapping xmlns="https://schemas.normalizedsystems.org/xsd/expanders/2025/0/0/mapping" strict="true">
  <artifact this="dataElement.packageName + '.' + dataElement.name + 'ImportantBean'" importStrategy="java"/>

  <uses eval="'jakarta.servlet.http.HttpServletRequest'"/>
  <uses eval="'jakarta.servlet.http.HttpServletResponse'"/>
</mapping>

In addition, it will be required to add a technology lexicon to map the imports back to the old javax equivalent. This in essence allows you to define how the imports should be rewritten if a specific technology is active in the model. Note that these are defined as data resources and will be inherited from dependencies. Many imports may already remap automatically if you depend on a resource such as Expanders that had its own technology lexicon.

<dataResource type="expansionControl::TechnologyLexicon">
<technologyLexicon>
  <technology name="JAVA_EE"/>
  <coordinateRedirections>
    <coordinateRedirection>
      <coordinate>jakarta.servlet.http.HttpServletRequest</coordinate>
      <target>javax.servlet.http.HttpServletRequest</target>
    </coordinateRedirection>
    <coordinateRedirection>
      <coordinate>jakarta.servlet.http.HttpServletResponse</coordinate>
      <target>javax.servlet.http.HttpServletResponse</target>
    </coordinateRedirection>
  </coordinateRedirections>
</technologyLexicon>
</dataResource>

Migrating applications​

When migrating applications there are only two important steps:

1. Updating the settings of the project to target Jakarta.
2. Migrate custom code in harvests and ext files if needed.

Updating project settings​

1. Upgrade your expansion settings (typically in conf/expansionSettings.conf) to use versions of expansion resources that support Jakarta EE.

2. In the technical infrastructure settings, the JEE version should be updated to 10:

   Java 21.xml

   <technicalInfrastructure name="Java 21">
     <javaVersion>jdk21</javaVersion>
     <jeeVersion>10</jeeVersion>
   </technicalInfrastructure>
   

3. Add the hibernate.version option with value 6 to your Application model.

   myapplication.xml

   <application name="myapplication">
     <shortName>myapplication</shortName>
     <version>1.0.0</version>
     <components>
       <component name="account"/>
       <component name="assets"/>
       <component name="utils"/>
       <component name="validation"/>
       <component name="workflow"/>
       <component name="applicationStuff"/>
     </components>
     <options>
       <hibernate.version>6</hibernate.version>
     </options>
   </application>
   

4. Update the TomEE base image for Docker to a TomEE 10 variant. The latest version can be found on the documentation page for the base image. Today, this is:

   • docker.normalizedsystems.org/nsx-tomee-base:10.1.2-3.11.1 for root-based images
   • docker.normalizedsystems.org/nsx-tomee-base:10.1.2-3.11.1-rootless for rootless images

Migrating custom code​

Most custom code will be compatible with Jakarta EE already and will not require any changes. The majority of required changes will be the package names that changed from javax.* to jakarta.*. These are easy to identify once you migrate the project settings and expand, as those imports will no longer be found. This is solved by simply replacing import javax. with import jakarta..

Version 9 of Expanders introduces support for Jakarta EE as part of an effort to support this across our entire ecosystem. This also marks the completion of the first phase of this migration, where the entire JEE base application stack is supported for both Java EE and Jakarta EE, including process automation.

Breaking change for Struts2​

With this release of Expanders, we support both Struts2 6.x and 7.x to match the different versions of JEE. Since Struts2 completely removed support for the fileUpload interceptor in version 7, we've now also removed it from our application stack. The reasoning behind this decision is that this interceptor was responsible for CVE-2024-53677, which has a score of 9.5 on the CVSS 4 scale. The alternative implementation using the actionFileUpload interceptor has been implemented across all of our expanders for several months now, but custom upload actions will also have to be refactored to switch to the new system. Regrettably, the impact of this change will not be visible at compile time, so care must be taking when upgrading to version 9 of Expanders.

• NIST listing: https://nvd.nist.gov/vuln/detail/CVE-2024-53677
• Sonatype article: https://www.sonatype.com/blog/cve-2024-53677-a-critical-file-upload-vulnerability-in-apache-struts2

Migration​

The migration is fairly straight-forward and is described in this migration guide from Struts2: https://struts.apache.org/core-developers/action-file-upload-interceptor

An action that handles uploads should be modified by implementing the UploadedFilesAware interface. With this interface comes a method withUploadedFiles() that should be implemented. To retain backwards compatibility with existing implementations, it is possible to set the values of existing fields in the class from this method, which were previously set dynamically by the old interceptor using reflection.

public class AssetUploader extends ActionSupport {

  private File uploadData; // the actual file
  private String uploadDataContentType; // the content type of the file
  private String uploadDataFileName; // the uploaded file name

public class AssetUploader extends ActionSupport implements UploadedFilesAware {

  private File uploadData; // the actual file
  private String uploadDataContentType; // the content type of the file
  private String uploadDataFileName; // the uploaded file name

  @Override
  public void withUploadedFiles(List<UploadedFile> uploadedFiles) {
    if (!uploadedFiles.isEmpty()) {
      final UploadedFile uploadedFile = uploadedFiles.get(0);
      this.uploadData = new File(uploadedFile.getAbsolutePath());
      this.uploadDataContentType = uploadedFile.getContentType();
      this.uploadDataFileName = uploadedFile.getOriginalName();
    }
  }