Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jakarta.activation-api classpath collision with jakarta.activation #112

Closed
aelgn opened this issue Oct 22, 2020 · 14 comments
Closed

jakarta.activation-api classpath collision with jakarta.activation #112

aelgn opened this issue Oct 22, 2020 · 14 comments

Comments

@aelgn
Copy link

aelgn commented Oct 22, 2020

The jackson-module-jaxb-annotations artifact pulls in the jakarta.activation:jakarta.activation-api dependency.

This causes classpath collisions for the activation api classes that are also included in com.sun.activation:jakarta.activation if this artifact is also a (transitive or not) dependency.

Ie. in Jetty you will get this warning at startup:
[WARNING] javax.activation.ActivationDataFlavor scanned from multiple locations: jar:file:///<snip>.m2/repository/com/sun/activation/jakarta.activation/1.2.1/jakarta.activation-1.2.1.jar!/javax/activation/ActivationDataFlavor.class, jar:file:///<snip>.m2/repository/jakarta/activation/jakarta.activation-api/1.2.1/jakarta.activation-api-1.2.1.jar!/javax/activation/ActivationDataFlavor.class

The fix in similar cases seems to be to change the jakarta.activation-api dependency to jakarta.activation
jakartaee/jaf-api#18
https://issues.apache.org/jira/browse/SPARK-27611

Is this in scope for jackson-module-jaxb-annotations or are users of the artifact meant to manually exclude/provide the activation api classes?

@cowtowncoder
Copy link
Member

Let's see if mr Module, @GedMarc can help here...

@GedMarc
Copy link
Contributor

GedMarc commented Oct 23, 2020

Simple update to 1.2.2 on activation-api, removal of activation :)

Please let me do this PR though, jaxb also has a funky thing on this (jaxrs base&impl)

@GedMarc
Copy link
Contributor

GedMarc commented Oct 23, 2020

backwards compatibility considerations :
module-info is placed in the root package in activation 1.2.2 - wildfly 10 and below, glassfish & payara 4.1 i think and below - spit out class errors for invalid class definitions,
Fixable by upgrading the jaxen version in the ee servers - haven't tried on websphere

Should i put this in the readme?

@cowtowncoder
Copy link
Member

@GedMarc Yes, I think a note on compatibility/work-arounds for README of jaxb-annotations module would make sense.

@GedMarc
Copy link
Contributor

GedMarc commented Oct 24, 2020

So 2.0.0 came out last night - it's in the jakarta namespace - contains both sets in the base, and retains API with duplicate classes,
I have logged a bug in EE4J that it is not JDK 11 compatible

I see PrimeFaces went the route of creating -jakarta artefacts with a shade to replace all javax. to jakarta.

1.2.2 module info, references the -api in the module declaration, it cannot be removed without a custom moditect, and you can't build JLink because it complains of packages found in two artefacts - I'm not sure if this can be resolved without customizing the base or waiting for the Jakarta guys

So far, my only solution is to use a custom packaged that resolves this for them, until they are up and running, to modularize properly.

It does not look like Jakarta 9 will be 100% JDK 11 compatible so far, Servlet 5 is in final and is not compatible, jakarta.mail is in final and is not compatible. EL 4.0 is in final and is also not compatible
You may need to wait until Jakarta 10

https://search.maven.org/artifact/com.guicedee.services/jakarta.activation

@aelgn
Copy link
Author

aelgn commented Oct 26, 2020

Okay. Thank you for the research and clarification 👍

@cowtowncoder
Copy link
Member

@GedMarc does #116 help here?

@GedMarc
Copy link
Contributor

GedMarc commented Nov 15, 2020

yes this is solved and pulled into 2.12.rc2

@GedMarc
Copy link
Contributor

GedMarc commented Nov 15, 2020

@aelgn Please check jdk11-compat test if you still have a problem and make issues there, this shouldn't come up at all if you use the <classifier>jakarta</classifier> for your pom

@aelgn
Copy link
Author

aelgn commented Nov 16, 2020

@GedMarc I tried adding the dependency

<dependency>
      <groupId>com.fasterxml.jackson.module</groupId>
      <artifactId>jackson-module-jaxb-annotations</artifactId>
      <version>2.12.0-rc2</version>
      <classifier>jakarta</classifier>
</dependency>

Which unfortunately only aggravated the problem :)

The javax.activation.* classes are still "scanned from multiple locations" and now the same problem appears for the javax.xml.bind.* package...

jar:file:///Users/elias/.m2/repository/org/jboss/spec/javax/xml/bind/jboss-jaxb-api_2.3_spec/1.0.1.Final/jboss-jaxb-api_2.3_spec-1.0.1.Final.jar!/javax/xml/bind/Binder.class, 
jar:file:///Users/elias/.m2/repository/jakarta/xml/bind/jakarta.xml.bind-api/2.3.2/jakarta.xml.bind-api-2.3.2.jar!/javax/xml/bind/Binder.class

Which is interesting, since I don't have the jakarta.xml.bind-api-2.3.2.jar in my dependency tree :/

@GedMarc
Copy link
Contributor

GedMarc commented Nov 16, 2020

ok so you need to make a choice then - but the change is successful 👍

if you want to use jakarta, then use jakarta - for annotation, activation, jaxb and jaxrs - :) otherwise you'll be creating the same issues all the time :)

You can use the coordinates here in the jdk 11 test lib - https://github.com/FasterXML/jackson-jdk11-compat-test/blob/038942f1aec95fd3443fca7700bcb9852efb5dd8/pom.xml#L41

@aelgn
Copy link
Author

aelgn commented Nov 17, 2020

@GedMarc not sure I fully understand... Do you mean there is a choice in using jackson-module-jaxb-annotations without getting the colliding jakarta-activation-api and jakarta.xml.bind-api artifacts?

... this shouldn't come up at all if you use the <classifier>jakarta</classifier> for your pom

Do you mean by adding <classifier>jakarta</classifier> to the jackson-module-jaxb-annotations dependency? That does not seem to have any influence on the class collisions... or is there a "without-jakarta" classifier? :)

I can however get rid of the jakarta api artifacts by excluding them from jackson-module-jaxb-annotations

    <dependency>
      <groupId>com.fasterxml.jackson.module</groupId>
      <artifactId>jackson-module-jaxb-annotations</artifactId>
      <version>2.12.0-rc2</version>
      <exclusions>
        <exclusion>
          <groupId>jakarta.activation</groupId>
          <artifactId>jakarta.activation-api</artifactId>
        </exclusion>
        <exclusion>
          <groupId>jakarta.xml.bind</groupId>
          <artifactId>jakarta.xml.bind-api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

I guess I'm just wondering if that is a requirement for using jackson with other jakarta-based dependencies going forward?

@GedMarc
Copy link
Contributor

GedMarc commented Nov 17, 2020

Wellllllll...

If you put them into your dependency management section with the right versions, you won't need to exclude them ;) it will switch to the right jakarta version with that namespace :)

What i meant was to use the dependency management feature to set the correct versions of everything to the jakarta namespace :)

@aelgn
Copy link
Author

aelgn commented Nov 17, 2020

@GedMarc Aha! Thank you for bearing with me. This did indeed solve the problem 👍 🥇

For posterity:

<dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.fasterxml.jackson</groupId>
        <artifactId>jackson-bom</artifactId>
        <version>2.12.0-rc2</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>jakarta.activation</groupId>
        <artifactId>jakarta.activation-api</artifactId>
        <version>2.0.0</version>
      </dependency>
      <dependency>
        <groupId>jakarta.xml.bind</groupId>
        <artifactId>jakarta.xml.bind-api</artifactId>
        <version>3.0.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement> 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants