As commented in , full #61 failed in neutron NeutronE2ETest AssertionError: L2 Gateway Delete Failed expected:<204> but was:<404> - that is not the same problem as the original broken Neutron in  (what was Singleton Network Post Failed NB expected:<201> but was:<400> in the IT ITNeutronE2E (not the standalone NeutronE2ETest) ... but this passed locally for me yesterday, still does - and also is green locally for , so we agreed together to add an @Ignore and we'll re-activate it after.

> there should be an easy local solution possible for the very short term by forcing usage of the old

I finally got this working, see https://git.opendaylight.org/gerrit/#/c/76089/14..15, but it required dependency management both in the project-neutron-parent and introducing a new neutron-single-feature-parent for all of Neutron's odl-neutron-* features.

In fact, we are just very lucky that the org.eclipse.persistence.moxy bundle does not specify a restrictive exclusive version range for its javax.json Import-Package (it has no version); if it did, then we would be screwed without any way out to override that, AFAIK.

may have future follow-up re. all this mess.

> idea here was to use the org.glassfish.jersey.moxy.json.MoxyJsonFeature and the org.glassfish.jersey.moxy.json.MoxyJsonConfig instead of the org.eclipse.persistence.jaxb.rs.MOXyJsonProvider

https://git.opendaylight.org/gerrit/#/c/76773/1/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/NeutronNorthboundRSApplication.java

FTR: The use of jersey-media-moxy (it's mere presence on the classpath by way of a dependency in northbound-api) also causes the following weird issue, which suspect  may fix; TBC later:

> read up more of the Jersey doc at this point. It seems it may be possible to configure it (Jersey) a little differently than we have in Neutron in the past, and get it to directly use Moxy, instead of the Jersey -> JAXB -> Moxy thing which we are currently (I think...) doing; this may help for this kind of class loading issue - hopefully.

My idea here was to use the org.glassfish.jersey.moxy.json.MoxyJsonFeature and the org.glassfish.jersey.moxy.json.MoxyJsonConfig instead of the org.eclipse.persistence.jaxb.rs.MOXyJsonProvider, following https://jersey.github.io/documentation/2.25.1/media.html#json.moxy - and I tried that, but it doesn't help, makes no difference...

... because the real problem here, of course is the Class.forName in javax.json.spi.JsonProvider which as we all know well is very problematic unde OSGi (I should have seen and jumped on that 2 weeks ago!). Looking more closely at that here https://github.com/eclipse-ee4j/jsonp/blob/master/api/src/main/java/javax/json/spi/JsonProvider.java we see that it attempts to use java.util.ServiceLoader for javax.json.spi.JsonProvider (of which we and probably the rest of the world doesn't have any), and then default to the hard-coded DEFAULT_PROVIDER = "org.glassfish.json.JsonProviderImpl" and a Class.forName for that. This seems to have been like this since the dawn of time in JSON-P (JSR 374), already back in https://github.com/javaee/jsonp/blob/json-1.0/api/src/main/java/javax/json/Json.java. So why did this suddenly break for us??

It's because org.eclipse.persistence.moxy 2.7.1 depended directly on org.glassfish:javax.json:jar 1.0.4, whereas (Moxy) 2.7.3 depends on javax.json:javax.json-api 1.1.2 and we (see above) then had to add an explicit extra dependeny ourselves to org.glassfish:javax.json - but now 1.1.2.

And whereas org.glassfish:javax.json:jar 1.0.4 fat packaged both packages javax.json as well as org.glassfish.json (AND THEREFORE THE Class.forName WORKED EVEN UNDER OSGi), the newer org.glassfish:javax.json 1.1.2 has (only) the org.glassfish.json packages, with a dep to the separate new javax.json:javax.json-api 1.1.2 which now contains (only) the javax.json packages. Nicer API / Impl split packaging - but breaking OSGi.

So the EclipseLink bump in https://git.opendaylight.org/gerrit/#/c/75508/ from 2.7.1 to 2.7.3 is the culprit for this "little" (hugely time consuming and blocked the Neon-MRI upgrade) problem.

What next? We most probably, hopefully, do not have to revert that (and cut a new odlparent...) - there should be an easy local solution possible for the very short term by forcing usage of the old org.glassfish:javax.json:jar 1.0.4 instead of 1.1.2 (and excluding javax.json:javax.json-api).