apache / tomcat-jakartaee-migration Goto Github PK

View Code? Open in Web Editor NEW

129.0 18.0 48.0 367 KB

Apache Tomcat migration tool for Jakarta EE

Home Page: https://tomcat.apache.org/

License: Apache License 2.0

Java 99.88% Shell 0.12%

tomcat-jakartaee-migration's Introduction

Apache Tomcat migration tool for Jakarta EE

Overview

The purpose of the tool is to take a web application written for Java EE 8 that runs on Apache Tomcat 9 and convert it automatically so it runs on Apache Tomcat 10 which implements Jakarta EE 9.

The tool can be used from the command line or as an Ant task.

Usage

Download

Download a source or binary distribution from https://tomcat.apache.org/download-migration.cgi

Build

Build the migration tool from source with:

./mvnw verify

To run the migration tool locally, you are most likely to want:

target/jakartaee-migration-*-shaded.jar

Migrate

Migrate your Servlet application with:

java -jar jakartaee-migration-*-shaded.jar <source> <destination>

The source should be a path to a compressed archive, a folder or an individual file. The destination will be created at the specified path as a resource of the same type as the source.

INFO This tool will remove cryptographic signatures from JAR files contained in the source, as the changed resources would not match them anymore.

A warning will be logged for each JAR file where the signature has been removed.

This tool is also available on Debian and Ubuntu systems by installing the tomcat-jakartaee-migration package and invoking the javax2jakarta command.

Ant task

The migration tool is available as an Ant task, here is an example:

<taskdef name="javax2jakarta" classname="org.apache.tomcat.jakartaee.MigrationTask" classpath="jakartaee-migration-*-shaded.jar"/>

<javax2jakarta src="webapp.war" dest="webapp.migrated.war" profile="tomcat"/>

Differences between Java EE 8 and Jakarta EE 9

The difference between Java EE 8 and Jakarta EE 9 is that all the Java EE 8 packages in the javax.* namespace have moved to the jakarta.* namespace. Some sub-packages have also been renamed. This migration tool performs all the necessary changes to migrate an application from Java EE 8 to Jakarta EE 9 by renaming each Java EE 8 package to its Jakarta EE 9 replacement. This includes package references in classes, String constants, configuration files, JSPs, TLDs etc.

Note: Not all javax.* packages are part of Java EE. Only those defined by Java EE have moved to the jakarta.* namespace.

Note: It is not necessary to migrate any references to XML schemas. The schemas don't directly reference javax packages and Jakarta EE 9 will continue to support the use of schemas from Java EE 8 and earlier.

Legal

This tool modifies web application content as described in the previous section. This may include modification of third-party provided content. It is strongly recommended that you confirm that the license(s) associated with any third-party content permit such modifications, especially if you intend to distribute the result.

tomcat-jakartaee-migration's People

Contributors

Stargazers

Watchers

tomcat-jakartaee-migration's Issues

List modified files

At the moment all files are shown that have been processed by the tool.

A list of all files that have been modified by the tools would be great to see, which (Jar) files must be updated.

EE package migration

Hi,

I'd like to know when a specific package is replaced (like javax.xml.bind replaced by jakarta.xml.bind), shall we need introduce some 3rd party dependency?
like:

<dependency>
    <groupId>jakarta.xml.bind</groupId>
    <artifactId>jakarta.xml.bind-api</artifactId>
    <version>4.0.0</version>
</dependency>

(our legacy code relies on jaxb-api)

I'm not sure what happened to the final output, like jaxb-api jar is removed and jakarta.xml.bind-api auto added?

And one more question, if I want to ignore some package replacement in:
https://github.com/apache/tomcat-jakartaee-migration/blob/main/src/test/java/org/apache/tomcat/jakartaee/EESpecProfileTest.java#L90-L118

How to handle it? could you point me to the code/config? so I can fork the repo and change it accordingly.

Thanks

Can I migrate oracle ords.war using this tool

I wish to deploy oracle ords.war on tomcat 10 can I migrate ords.war and deploy on it. Because ords not working when department on tomcat 10. Any solution?

Migrates packages that should not be migrated

I'm using javax.annotation and the tool rewrote these to jakarta.annotation.

Removing signature from JAR file with JCE providers leads to SecurityException

If this migration tool removes the cryptographic signature from a JAR file which contains JCE providers (e.g., Bouncy Castle), Java refuses to use these providers afterward:

java.lang.SecurityException: JCE cannot authenticate the provider BC
[...]
Caused by: java.util.jar.JarException: file:/tmp/[...]/bcprov-ext-jdk15on-1.65.jar has unsigned entries - org/bouncycastle/LICENSE.class

I see two possible solutions:

If the classes in a JAR file do not have dependencies on Java EE classes, the JAR file is not touched by this migration tool. This means that the signature remains intact.
If a JAR file contains JCE providers, it is not touched by this migration tool. Instead, a warning is printed.

I think that solution 1 is easier to implement, since it does not require special knowledge about JCE providers (or other features which require signed JAR files).

Bouncy Castle's main JAR file does not have dependencies on any Java EE classes. This means that both solutions would work for it.

v1.0.3 causes java.lang.IllegalArgumentException: java.io.EOFException on certain Tomcat War deployments

Hi,

couldn't wait to try out the latest and greatest version released a couple of days ago as it fixes e.g. #29
Unfortunately I ran into another issue but I'm not quite sure if it's the right repo to report or if it's something Tomcat-related. As it doesn't happen with v1.0.0 I guess it's the Tomcat Migration Tool and not Tomcat though.

I'm using a Dockerfile to build/create my web application as a WAR file and migrate jars (roughly 30) in my project.

The expected output when I start the container via Docker Compose would be something like:

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
13-Sep-2022 10:50:00.504 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name:   Apache Tomcat/10.1.0-M17
13-Sep-2022 10:50:00.507 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          Jul 13 2022 18:51:03 UTC
13-Sep-2022 10:50:00.507 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 10.1.0.0
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Linux
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            5.15.0-46-generic
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:             /opt/java/openjdk
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version:           17.0.4.1+1
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:            Eclipse Adoptium
13-Sep-2022 10:50:00.508 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:         /usr/local/tomcat
13-Sep-2022 10:50:00.509 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:         /usr/local/tomcat
13-Sep-2022 10:50:00.517 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
13-Sep-2022 10:50:00.517 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
13-Sep-2022 10:50:00.517 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED
13-Sep-2022 10:50:00.517 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
13-Sep-2022 10:50:00.517 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/local/tomcat
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/local/tomcat
13-Sep-2022 10:50:00.518 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
13-Sep-2022 10:50:00.525 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [2.0.1] using APR version [1.7.0].
13-Sep-2022 10:50:00.529 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 3.0.2 15 Mar 2022]
13-Sep-2022 10:50:00.735 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
13-Sep-2022 10:50:00.759 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [389] milliseconds
13-Sep-2022 10:50:00.797 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
13-Sep-2022 10:50:00.797 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.1.0-M17]
13-Sep-2022 10:50:00.811 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/ROOT.war]
13-Sep-2022 10:50:01.197 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
13-Sep-2022 10:50:01.231 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/ROOT.war] has finished in [420] ms
13-Sep-2022 10:50:01.234 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
13-Sep-2022 10:50:01.243 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [484] milliseconds

The error I get is:

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
13-Sep-2022 10:49:31.037 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name:   Apache Tomcat/10.1.0-M17
13-Sep-2022 10:49:31.041 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          Jul 13 2022 18:51:03 UTC
13-Sep-2022 10:49:31.041 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 10.1.0.0
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Linux
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            5.15.0-46-generic
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:             /opt/java/openjdk
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version:           17.0.4.1+1
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:            Eclipse Adoptium
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:         /usr/local/tomcat
13-Sep-2022 10:49:31.042 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:         /usr/local/tomcat
13-Sep-2022 10:49:31.052 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
13-Sep-2022 10:49:31.052 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
13-Sep-2022 10:49:31.052 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED
13-Sep-2022 10:49:31.052 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/local/tomcat
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/local/tomcat
13-Sep-2022 10:49:31.053 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
13-Sep-2022 10:49:31.059 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [2.0.1] using APR version [1.7.0].
13-Sep-2022 10:49:31.063 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 3.0.2 15 Mar 2022]
13-Sep-2022 10:49:31.289 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
13-Sep-2022 10:49:31.308 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [408] milliseconds
13-Sep-2022 10:49:31.341 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
13-Sep-2022 10:49:31.341 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.1.0-M17]
13-Sep-2022 10:49:31.354 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/ROOT.war]
13-Sep-2022 10:49:31.403 SEVERE [main] org.apache.catalina.startup.HostConfig.deployWAR Error deploying web application archive [/usr/local/tomcat/webapps/ROOT.war]
	java.lang.IllegalStateException: Error starting child
		at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729)
		at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
		at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
		at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:976)
		at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1950)
		at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
		at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
		at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
		at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123)
		at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:777)
		at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
		at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1657)
		at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
		at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
		at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
		at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
		at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946)
		at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:886)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
		at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
		at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
		at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
		at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
		at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
		at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:252)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:926)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.startup.Catalina.start(Catalina.java:795)
		at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
		at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
		at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
		at java.base/java.lang.reflect.Method.invoke(Method.java:568)
		at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
		at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
	Caused by: org.apache.catalina.LifecycleException: Failed to initialize component [org.apache.catalina.webresources.JarResourceSet@2dfaea86]
		at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
		at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:139)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:173)
		at org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:737)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4833)
		at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4971)
		at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
		at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
		... 37 more
	Caused by: java.lang.IllegalArgumentException: java.io.EOFException: Expected:46, read:0
		at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:142)
		at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
		... 44 more
	Caused by: java.io.EOFException: Expected:46, read:0
		at java.base/java.util.jar.JarFile.getBytes(JarFile.java:818)
		at java.base/java.util.jar.JarFile.getManifestFromReference(JarFile.java:420)
		at java.base/java.util.jar.JarFile.getManifest(JarFile.java:407)
		at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:140)
		... 45 more
13-Sep-2022 10:49:31.405 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/ROOT.war] has finished in [51] ms
13-Sep-2022 10:49:31.407 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
13-Sep-2022 10:49:31.416 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [108] milliseconds

After having a look at the jars and the file size differences between migrated ones with 1.0.0 and 1.0.3 I could figure out four jars where I can reproduce the issue at any time.
As a reproducer I've written a simple Dockerfile which:

makes use of the Tomcat Sample Application
downloads the jars from Maven Repository
downloads the Tomcat Migration Tool from Maven Repository

# syntax=docker/dockerfile:1

FROM tomcat:10.1.0-M17

ARG MIG_VER=1.0.0
ARG MVN_URL=https://repo1.maven.org/maven2

WORKDIR /jar-java

RUN apt-get -qq update; \
        apt-get install -y --no-install-recommends -qq zip unzip wget; \
        wget -q "${MVN_URL}/isorelax/isorelax/20020414/isorelax-20020414.jar"; \
        wget -q "${MVN_URL}/net/java/dev/jna/jna-platform/4.5.1/jna-platform-4.5.1.jar"; \
        wget -q "${MVN_URL}/msv/msv/20020414/msv-20020414.jar"; \
        wget -q "${MVN_URL}/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar"; \
        wget -q "${MVN_URL}/org/apache/tomcat/jakartaee-migration/${MIG_VER}/jakartaee-migration-${MIG_VER}-shaded.jar" -O /jakartaee-migration.jar; \
        java -jar /jakartaee-migration.jar \
#               -exclude=isorelax* \
#               -exclude=jna-platform* \
#               -exclude=msv* \
#               -exclude=relaxngDatatype* \
        /jar-java /jar-jakarta; \
        wget -q "https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.war"; \
        unzip sample.war; \
        cp -r /jar-jakarta/*.jar WEB-INF/lib; \
        zip -r /usr/local/tomcat/webapps/ROOT.war WEB-INF META-INF hello.jsp images index.html

WORKDIR /usr/local/tomcat

If you build a container image using something like docker buildx build --progress plain -t sample-war . and create a container like docker run --rm sample-war the web application gets deployed as expected.
If you change the version (line 5) in the Dockerfile from 1.0.0 to 1.0.3, build the image and create the container again you will end up with the posted java.io.EOFException.
If you exclude (uncomment lines 18 to 21 in the Dockerfile) all four jars and do the same again the application again gets deployed as expected.

Would be great if we could sort this out somehow. Unfortunately I don't get any more detailed logs even if I set the log level to FINEST in the web application itself and Tomcat.

TIA

Copyright and Derived Works

Can you provide a statement in the README.md that describes the changes made by this tool?

It is customary for software EULAs to include language like the following:

5. You may not reverse engineer the Software (such as by stepping through it with a debugger). You may not adapt, modify, translate or create derived works of the Software or accompanying documentation or any copy thereof, in whole or in part.

This raises an issue as to whether or not running this tool on a jar file creates a derived work that would violate a statement like the above.

My feeling is that if the resulting jar is logically and functionally equivalent, then it is not a derived work, it is still the original work and therefore converting a library with this tool would not be a violation of an EULA with language like the above.

However I do not know from glancing at the code, and I do not have authority to say, if the tool makes changes that are not logically and functionally equivalent.

Can it be said that the only changes this tool makes are to package names? Or does it do more? Does it change method signatures, parameter types, or anything that might be construed as code?

Support jspf as text file type

We have some web applications containing JSP fragments (extension .jspf) which were not processed as expected.

Could jspf be added as a supported extension?

facing issue while migrating the war

I am trying to deploy a war in which there is a class extending javax.servet.ServletContextListener and overriding method contextIntialized(javax.servlet.ServletContextEvent) method.
After migrating the war using the tomcat-jakartaee-migration tool, the following issue is resolved.
java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener

But now it is looking for overriden method contextIntialized(jakarta.servlet.ServletContextEvent) but in actual code it is contextIntialized(javax.servlet.ServletContextEvent).
Since the migration tool is in progress now, I wanted to ask if there is a plan to handle such a scenario as well while migration or it should be handled by application developers themselves?

And if there is a plan to handle such a scenario then may I know the expected timeline it is planned for?

Thanks

How can I add .groovy file support that do not get converted to .class files

I have Groovy files having .groovy extensions that do not get compiled to .class file even after deployment. But they still have text based entries on those files like: import javax.servlet.http.HttpServletResponse.

Where should I change to add support for such files?

Thanks

The AJP Connector is configured with secretRequired="true"

Kindly help with the below issue-:

25-Feb-2023 00:18:50.221 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to start component [Connector[AJP/1.3-7009]]
org.apache.catalina.LifecycleException: Protocol handler start failed
at org.apache.catalina.connector.Connector.startInternal(Connector.java:1076)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:447)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:347)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid.
at org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:267)
at org.apache.catalina.connector.Connector.startInternal(Connector.java:1073)
... 12 more
25-Feb-2023 00:18:50.223 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [1048] milliseconds
(END) Connection to 10.252.4.140 closed by remote host.

Spring boot version - 2.0.0.RELEASE and tomcat 9.0.70, maven 3.6.x, java 8

"java.util.zip.ZipException: invalid entry size (expected 0 but got 913 bytes)" when opening migrated jar with `java.util.zip.ZipInputStream`

Context

I'm investigating https://youtrack.jetbrains.com/issue/KT-57767 where the build fails when reading
tomcat-embed-core-10.1.7-jakartaee.jar

(Note: If you download the above file, you'll get a .zip file because GitHub doesn't accept uploading .jars so I had to rename it to .zip.)

That jar was converted from tomcat-embed-core-10.1.7.jar by the Gradle Jakarta EE Migration plugin, which uses the Apache Tomcat migration tool for Jakarta EE.

If I open the migrated jar using java.util.zip.ZipInputStream, I'll get:

java.util.zip.ZipException: invalid entry size (expected 0 but got 913 bytes)

If I open it using java.util.zip.ZipFile, I'll get:

java.util.zip.ZipException: invalid CEN header (bad signature)

This suggests that there is a bug in either ZipInputStream (e.g., https://bugs.openjdk.org/browse/JDK-8298530), ZipFile, the tomcat-jakartaee-migration tool, or a combination of them.

Request

Please investigate whether this is a bug in the tomcat-jakartaee-migration tool.

Even if it isn't, it would still be nice to change the way the tool generates migrated jars such that they can be read by ZipInpuStream or ZipFile API.

Also rename JMS, Java Mail and other web.xml definitions

Currently, the Jakarta EE migration tool seems to be leaving definitions in web.xml such as the below untouched:

  <resource-ref>
    <description>The test JMS queue</description>
    <res-ref-name>jms/MyQueue</res-ref-name>
    <res-type>javax.jms.Queue</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

These also need to be adapted, to use the Jakarta EE equivalents.

Does this project work in a spring 5 project?

I assume spring 5 project is not supported, since below codes,

tomcat-jakartaee-migration/src/main/java/org/apache/tomcat/jakartaee/Migration.java

Lines 85 to 88 in d8b33d3

 DEFAULT_EXCLUDES.add("spring-aop-*.jar"); 

 DEFAULT_EXCLUDES.add("spring-expression-*.jar"); 

 DEFAULT_EXCLUDES.add("spring-security-crypto-*.jar"); 

 DEFAULT_EXCLUDES.add("spring-security-rsa-*.jar");

Is this true?

java.lang.IllegalArgumentException: Unknown Entity bean class with eclipselink in tomcat 10

Im trying to upgrade spring web app to tomcat 10 for the upgrade im using apache jakarta migration tool. the application got successfully migrated using this tool but when i run the application in tomcat 10 im facing following issue

java.lang.IllegalArgumentException: Unknown Entity bean class please verify that this class has been marked with the @entity annotation.

and tables are not being created in the database.

when i run same application in tomcat 9 the tables are being created and i dont face any exception there.

i cant able to figure what is the problem in tomcat 10 even after using migration tool.

Exception occured while sending Websocket Message and the session is being closed.

Hi,

I am trying to send the Message from the Websocket Server using "session.getBasicRemote().sendText("message");" , I got the IO exception message" The current thread was interrupted while waiting for a blocking send to complete " and the Websocket Session being closed due to the exception.

This Issue is happening while I am trying to run multiple threads parallely to send the message on the same session object, Note: the method to send the Wesocket Message is Synchronised, still I am getting the Exception.

Tomcat Version used- 8.5.11.

Can anyone please help me to solve this issue. Thanks in advance.

Regards,
Karthikeyan

Request to support ear file type as archive file

Now the migration tools only recognize jar, war, zip as archive file (

tomcat-jakartaee-migration/src/main/java/org/apache/tomcat/jakartaee/Migration.java

Line 416 in 4b767e4

 return fileName.endsWith(".jar") || fileName.endsWith(".war") || fileName.endsWith(".zip"); 

), request to add ear as archive file.

Do not migrate javax.xml.namespace

Execute the CLI on javax.xml.xpath.XPathConstants and you get jakarta namespace whereas it should stay javax.
Guess the EEProfile thing will need to move to something configurable since it only handles very particular cases today.

How can I know the migrated jar is actually "touched" or not after running MigrationCLI

Hi,

I'm using MigrationCLI.migrate to do jar to jar mutation.

I'd like to know whether the jar is modified or not after CLI.
Since I may apply different policy against this, like "keep the original jar" or "upload the transformed jar".

I guess the migration process must left some foot prints to indicate the which classes are modified.
If not, can I do checksum against original jar and transformed jar to determine whether it's touched or not?

Thanks in advance!

Leon

activemq 5.16.x not working after converting javax to jakarta using tomcat transformer

I am using tomcat transformer for javax to jakarta conversion, in the similar lines I converted my activemq-all 5.16.7 into jakarta using the same tomcat transformer, no errors during compilation, but while running the application it is not returning from below line: "ConnectionFactory.createConnection()"

means it is not able to establish the connection with broker.

Appreciate any help.

Download of Release

Is there any download of the released version? For example in bintray or maven repository. I was not able to find it.

Workaround for JDK-8303866 makes migrated jar incompatible with latest JDK releases

The zip validation changes for JDK-8302483 causes failures to load jars output by the migration tool:

lombok-1.18.28.jar; Invalid CEN header (invalid zip64 extra data field size)

The problem appears to be the workaround for JDK-8303866, the field removal appears to cause the problem:

https://github.com/apache/tomcat-jakartaee-migration/blob/4b767e426dfa1cf4b565eb328d51fe1ddb043825/src/main/java/org/apache/tomcat/jakartaee/Migration.java#L317C40-L320

We're currently using in-memory transforms as a workaround, but because we're using the tool in https://github.com/nebula-plugins/gradle-jakartaee-migration-plugin/ and they run in parallel, that can lead to heap utilization issues in builds.

These Lombok jars are the only ones we've run into trouble with.

Does this work tool work at the source or binary level?

From the documentation, it is unclear to me if this tools updates source code or if it manipulates bytecode. Which is it? Thanks.

Manifest in exploded osgi bundle is not migrated

Hi,

When running the migration on a war file that contains an exploded osgi bundle the class files and jar files within the exploded bundle are migrated but the manifest file is not.

An example of the war archive layout with an exploded osgi bundle could be

WEB-INF/
WEB-INF/bundles/
WEB-INF/bundles/com.example.service/
WEB-INF/bundles/com.example.service/META-INF/
WEB-INF/bundles/com.example.service/META-INF/MANIFEST.MF <--- not migrated
WEB-INF/bundles/com.example.service/lib/
WEB-INF/bundles/com.example.service/lib/com.example.code.jar <--- migrated

For bundles that are not exploded, the manifest along with classes and jar files inside the bundle are all migrated

WEB-INF/
WEB-INF/bundles/
WEB-INF/bundles/com.example.service.jar <--- everything is migrated

From looking at the code of the class org.apache.tomcat.jakartaee.ManifestConverter the issue appears to be that the check for migrating a manifest will only work when the manifest file is at the root of an archive because it expects to find the parent folder name in the entry name, e.g. "META-INF/MANIFEST.MF", but when running on an exploded artifact then the file name for the entry will be a path inside the parent archive, e.g. "WEB-INF/bundles/com.example.service/META-INF/MANIFEST.MF" from the example above.

ability to ignore file extensions?

I've been using this tool, to try out an entire stack with these changes, and we have one webapp which is a JRuby application.

Using this tool on the war file produced by our JRuby build, results in a failure:

Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo.txt]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo.txt]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/baz/]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/baz/]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/baz/foo.txt]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/foo/bar/baz/foo.txt]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/food.txt]
Migrating stream [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/globTest/food.txt]
Migrating Jar entry [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/gpbit3stored.zip]
Migrating archive [WEB-INF/gems/gems/rubyzip-1.2.2/test/data/gpbit3stored.zip]
Error performing migration

No additional details are given on the reason for the failure.
Still looking into why the rubyzip gem has piles of test data in it... but that aside, it would be nice to tell this tool to ignore .txt and .zip files...

javax.xml.(registry|rpc) were not migrated to jakarta namespace

so they should be left untouched (unless someone did that work in some fork...)

Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry META-INF/MANIFEST.MF

Hi,

with the release of version 1.0.1 of the Tomcat Migration Tool for Jakarta EE I'm having some issues with a couple of jar files in my project which cannot be migrated due to an exception. Same jar(s) can be migrated using version 1.0.0:

jakartaee-migration-1.0.1-shaded.jar

$ java -jar jakartaee-migration-1.0.1-shaded.jar jna-platform-4.5.1.jar jna-platform-4.5.1.jar.jakarta 
Performing migration from source [/jna-platform-4.5.1.jar] to destination [/jna-platform-4.5.1.jar.jakarta] with Jakarta EE specification profile [TOMCAT]
Migration starting for archive [jna-platform-4.5.1.jar] using streaming
Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry META-INF/MANIFEST.MF: 16b8446c instead of 4535229
	at org.apache.tomcat.jakartaee.commons.compress.archivers.zip.ZipArchiveOutputStream.handleSizesAndCrc(ZipArchiveOutputStream.java:718)
	at org.apache.tomcat.jakartaee.commons.compress.archivers.zip.ZipArchiveOutputStream.closeArchiveEntry(ZipArchiveOutputStream.java:607)
	at org.apache.tomcat.jakartaee.Migration.migrateArchiveStreaming(Migration.java:228)
	at org.apache.tomcat.jakartaee.Migration.migrateStream(Migration.java:285)
	at org.apache.tomcat.jakartaee.Migration.migrateFile(Migration.java:197)
	at org.apache.tomcat.jakartaee.Migration.execute(Migration.java:163)
	at org.apache.tomcat.jakartaee.MigrationCLI.main(MigrationCLI.java:94)
	Suppressed: java.io.IOException: This archive contains unclosed entries.
		at org.apache.tomcat.jakartaee.commons.compress.archivers.zip.ZipArchiveOutputStream.finish(ZipArchiveOutputStream.java:534)
		at org.apache.tomcat.jakartaee.commons.compress.archivers.zip.ZipArchiveOutputStream.close(ZipArchiveOutputStream.java:1090)
		at org.apache.tomcat.jakartaee.Migration.migrateArchiveStreaming(Migration.java:214)
		... 4 more

jakartaee-migration-1.0.0-shaded.jar

$ java -jar jakartaee-migration-1.0.0-shaded.jar jna-platform-4.5.1.jar jna-platform-4.5.1.jar.jakarta 
Performing migration from source [/jna-platform-4.5.1.jar] to destination [/jna-platform-4.5.1.jar.jakarta] with Jakarta EE specification profile [TOMCAT]
Migration starting for archive [jna-platform-4.5.1.jar] using streaming
Migration finished for archive [jna-platform-4.5.1.jar]
Migration completed successfully in [529] milliseconds

Java version: OpenJDK 11 as well as OpenJDK 17
OS version: Ubuntu 22.04 as well as 20.04

Simple reproducer:

fire up a OpenJDK Docker container, e.g. docker run -it --rm openjdk:11 bash
download an affected jar like Java Native Access Platform 4.5.1
download Tomcat Migration Tool for Jakarta EE 1.0.1
try to migrate the jar, e.g. java -jar jakartaee-migration-1.0.1-shaded.jar jna-platform-4.5.1.jar jna-platform-4.5.1.jar.jakarta

Vulnerability with Apache Commons Compress v1.20

The Apache Commons Compress v1.20 library included in this library has following CVEs associated:

Identifier	Published	Overall Score
NVD CVE-2021-35516 (BDSA-2021-2075)	Jul 13, 2021	7.5 High
NVD CVE-2021-35517 (BDSA-2021-2078)	Jul 13, 2021	7.5 High
NVD CVE-2021-36090 (BDSA-2021-2073)	Jul 13, 2021	7.5 High
NVD CVE-2021-35515 (BDSA-2021-2076)	Jul 13, 2021	7.5 High

Skipping files

Hi Guys

I tried to skip these kind of jars ( [WEB-INF/lib/jcl-over-slf4j-1.7.21.jar] ) with -exclude=**WEB-INF/lib/*.jar. but seems it is not working. Any idea or what should be the glob pattern to skip WEB-INF/lib/ jar files?

A way to skip conversion for libraries in WEB-INF/lib

Hi first of all, thanks for the efforts for this plugin. This is not an issue but asking a way to skip conversion of libraries inside a war (WEB-INF/lib). Because libraries do not get changed often so we can save time on conversion between builds (After converting for the first time). So when deployed, old libraries can be manually copied and replaced on the server.

Fix (remove) "javax.servlet.*" package version when processing the MANIFEST.MF

When "javax.servlet.*" package is specified in the MANIFEST.MF with version constraints like:

Import-Package: javax.servlet;version="[3.1.0,5.0.0)",
 javax.servlet.http;version="[3.1.0,5.0.0)",

it is converted to:

Import-Package: jakarta.servlet;version="[3.1.0,5.0.0)",
 jakarta.servlet.http;version="[3.1.0,5.0.0)",

and leads to unresolved dependencies in OSGi environment.
Removing or updating the version constraint to include 5 will fix the problem.

	DEFAULT_EXCLUDES.add("spring-aop-*.jar");
	DEFAULT_EXCLUDES.add("spring-expression-*.jar");
	DEFAULT_EXCLUDES.add("spring-security-crypto-*.jar");
	DEFAULT_EXCLUDES.add("spring-security-rsa-*.jar");

apache / tomcat-jakartaee-migration Goto Github PK

tomcat-jakartaee-migration's Introduction

Apache Tomcat migration tool for Jakarta EE

Overview

Usage

Download

Build

Migrate

Ant task

Differences between Java EE 8 and Jakarta EE 9

Legal

tomcat-jakartaee-migration's People

Contributors

Stargazers

Watchers

Forkers

tomcat-jakartaee-migration's Issues

Context

Request

jakartaee-migration-1.0.1-shaded.jar

jakartaee-migration-1.0.0-shaded.jar

Recommend Projects

Recommend Topics

Recommend Org