Uploaded image for project: 'neutron'
  1. neutron
  2. NEUTRON-200

Figure out permanent solution for Moxy / javax.json OSGi problem

    XMLWordPrintable

Details

    • Bug
    • Status: Confirmed
    • High
    • Resolution: Unresolved
    • None
    • None
    • northbound-api
    • None

    Description

      Once the Neon MRI stress (TSC-132) is over, we probably should look at a more permanent solution for the OSGi problems related to Moxy and the javax.json which I battled with in NEUTRON-197. Some options for further discussions:

      1. We could revert from the EclipseLink bump from from 2.7.1 to 2.7.3, remove the workarounds, and stay on 2.7.1 forever. That's not so great.

      2. The workarounds I put into neutron/parent/pom.xml and into the each odl-neutron-* single feature perhaps could move to odlparent instead of staying in neutron. I don't really like that though, because IMHO it's better for neutron to be able to "control its destiny" and set these version correctly itself; the problem with this is when odlparent next bumps its version of org.eclipse.persistence, it will probably be a mess (bit if anyone has a clear idea how to avoid repeating of org.eclipse.persistence from odlparent in project-neutron-parent, that would address that). More importantly, if we just shuffle ("upstream") that workaround, we would essentially still be eternally stuck on org.glassfish:javax.json version 1.0.4 ...

      3. Ideally, we should therefore find a real solution with EclipseLink & javax.json upstreams. What they should really do IMHO is EITHER continue to provide a single JAR including both API & Impl, for those like us under OSGi who were just fine with that, or for javax.json to allow specifying an Impl programmatically instead of via ServiceLoader and/or Class forName, and then for EclipseLink to allow us to set that... that's probably quite a bit of work to drive this end to end from start to completion (issues, contributions, tests, releases, upgrades); my motivation for that is limited.

      4. Alternatively, we could perhaps use the latest org.glassfish:javax.json and javax.json:javax.json-api and do some Bundle Buddy Policy something hack to make the Class.forName work after all.

      5. We could repackage (the latest version of) javax.json:javax.json-api + org.glassfish:javax.json together into a new combined bundle ourselves? With a Maven POM, not manually; and have our own artifact for this (in like odlparent or infrautils), and override dependencies to use that.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              Unassigned Unassigned
              vorburger Michael Vorburger
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: