Uploaded image for project: 'Java Parent Project'
  1. Java Parent Project
  2. JPAR-139

Multiple copies of Javabeans Activation Framework

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.11.0
    • Fix Version/s: 11.0.0
    • Labels:
      None

      Description

      I'm describing this in JPAR because ultimately this is probably going to need to be resolved at the level of the parent project, but there are implications for at least OpenSAML and the IdP.

      I'll start with the IdP observation. In IdP v3, we have one copy of the Javabeans Activation Framework (JAF) in the form of WEB-INF/lib/activation-1.1.jar. This is managed in the java-parent-project POM as javax.activation:activation:1.1.This version hails from 2006 and contains the following packages:

      • javax.activation (the API)
      • com.sun.activation.registries (implementation?)
      • com.sun.activation.viewers (implementation?)

      In current snapshots of the v4 IdP, we have no less than three files:

      • activation-1.1.1.jar
        • javax.activation:activation:1.1.1 (note new version number, from 2009).
        • managed by java-parent-project
        • contains the API and the implementation
      • javax.activation-api-1.2.0.jar
        • javax.activation:activation-api:1.2.0 (from 2017)
        • just contains the javax.activation API
        • pulled in via Hibernate, I think
      • jakarta.activation-api-1.2.1.jar
        • jakarta.activation:jakarta.activation-api:jar:1.2.1 (from 2018)
        • just contains the javax.activation API
        • pulled in via Hibernate, I think

      My evidence for the Hibernate source of these others is from the following dependency:tree extract from opensaml-storage-impl:

      [INFO] +- org.hibernate:hibernate-core:jar:5.4.2.Final:compile
      [INFO] |  +- org.jboss.logging:jboss-logging:jar:3.3.2.Final:compile
      [INFO] |  +- javax.persistence:javax.persistence-api:jar:2.2:compile
      [INFO] |  +- org.javassist:javassist:jar:3.24.0-GA:compile
      [INFO] |  +- net.bytebuddy:byte-buddy:jar:1.9.10:compile
      [INFO] |  +- antlr:antlr:jar:2.7.7:compile
      [INFO] |  +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.1.1.Final:compile
      [INFO] |  +- org.jboss:jandex:jar:2.0.5.Final:compile
      [INFO] |  +- com.fasterxml:classmate:jar:1.3.4:compile
      [INFO] |  +- javax.activation:javax.activation-api:jar:1.2.0:compile
      [INFO] |  +- org.dom4j:dom4j:jar:2.1.1:compile
      [INFO] |  +- org.hibernate.common:hibernate-commons-annotations:jar:5.1.0.Final:compile
      [INFO] |  +- javax.xml.bind:jaxb-api:jar:2.3.1:compile
      [INFO] |  \- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile
      [INFO] |     +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile
      [INFO] |     +- org.glassfish.jaxb:txw2:jar:2.3.2:compile
      [INFO] |     +- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile
      [INFO] |     +- org.jvnet.staxex:stax-ex:jar:1.8.1:compile
      [INFO] |     +- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.16:compile
      [INFO] |     \- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile
      

      Of course, this may not be the only source: it's the only one I found, in passing, because the Javadoc generation in JPAR-129 noticed the multiple sources of the javax.activation package and gave me a screen-full of errors.

      All of these are going to end up on the classpath, and I don't think that can be assumed to end well for anyone.

      I need to look into how this is supposed to work, but my suspicion is:

      • We probably should not be shipping an implementation of the JAF any more, but perhaps referring to it as a provided dependency
      • Regardless, we shouldn't be shipping the 2009 version at all. If not, this restriction should be enforced.
      • We might want to ship one or other of the API packages which provide the API, but only one of them. We need to manage dependencies on the one we want, enforce exclusion of the other one, and manage dependencies on hibernate and its jaxb-runtime dependency to exclude the one we don't want.

      I will note that if you Google around you can find other people with related issues, for example:

      Looks like a bit of a mess, in fact.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              ian@iay.org.uk Ian Young
              Reporter:
              ian@iay.org.uk Ian Young
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - Not Specified
                  Not Specified
                  Logged:
                  Time Spent - 2 hours, 4 minutes
                  2h 4m