https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NEUTRON-154 neutron <p>The <a href="https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018" class="external-link" target="_blank" rel="nofollow noopener">"big bump" of odlparent &amp; yangtools</a> with <a href="https://git.opendaylight.org/gerrit/#/c/66509/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/66509/</a> breaks Neutron:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[INFO] --- maven-failsafe-plugin:2.20.1:integration-test (default) @ integration-test --- [INFO] [INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] Running org.opendaylight.neutron.e2etest.ITNeutronE2E (...) Karaf started in 1s. Bundle stats: 12 active, 12 total [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 221.886 s &lt;&lt;&lt; FAILURE! - in org.opendaylight.neutron.e2etest.ITNeutronE2E [ERROR] test(org.opendaylight.neutron.e2etest.ITNeutronE2E) Time elapsed: 195.033 s &lt;&lt;&lt; FAILURE! java.lang.AssertionError: Network Collection GET to URL http://127.0.0.1:8181/controller/nb/v2/neutron/networks with wait failed at org.opendaylight.neutron.e2etest.ITNeutronE2E.test(ITNeutronE2E.java:90)</pre> </div></div> <p>The cause is this which can be seen in integration/test/target/exam/.../data/log/karaf.log:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2018-01-15T14:42:51,103 | ERROR | qtp881932043-138 | ContainerResponse | 35 - com.sun.jersey.jersey-server - 1.17.0 | The registered message body writers compatible with the MIME media type are: */* -&gt; com.sun.jersey.core.impl.provider.entity.FormProvider com.sun.jersey.core.impl.provider.entity.MimeMultipartProvider com.sun.jersey.core.impl.provider.entity.StringProvider com.sun.jersey.core.impl.provider.entity.ByteArrayProvider com.sun.jersey.core.impl.provider.entity.FileProvider com.sun.jersey.core.impl.provider.entity.InputStreamProvider com.sun.jersey.core.impl.provider.entity.DataSourceProvider com.sun.jersey.core.impl.provider.entity.XMLJAXBElementProvider$General com.sun.jersey.core.impl.provider.entity.ReaderProvider com.sun.jersey.core.impl.provider.entity.DocumentProvider com.sun.jersey.core.impl.provider.entity.StreamingOutputProvider com.sun.jersey.core.impl.provider.entity.SourceProvider$SourceWriter com.sun.jersey.server.impl.template.ViewableMessageBodyWriter com.sun.jersey.core.impl.provider.entity.XMLRootElementProvider$General com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$General 2018-01-15T14:42:51,103 | ERROR | qtp881932043-138 | ContainerResponse | 35 - com.sun.jersey.jersey-server - 1.17.0 | Mapped exception to response: 500 (Internal Server Error) javax.ws.rs.WebApplicationException: com.sun.jersey.api.MessageException: A message body writer for Java class org.opendaylight.neutron.northbound.api.NeutronNetworkRequest, and Java type class org.opendaylight.neutron.northbound.api.NeutronNetworkRequest, and MIME media type application/json was not found at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285) [35:com.sun.jersey.jersey-server:1.17.0]</pre> </div></div> <p>There are other exceptions in the log, but those are not causing this problem; notably the problem below is unrelated, even though it seem to sometimes cause the ITNeutronE2E to at first fail with org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker, but on retrying a build it will get it and hit above, this problem is something else which <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt" class="user-hover" rel="skitt">skitt</a> says he has a solution coming up for in controller:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2018-01-15T14:39:56,109 | ERROR | ConfigFeatureListener - ConfigPusher | FeatureConfigPusher | 47 - config-persister-feature-adapter - 0.8.0.SNAPSHOT | Giving up (after 100 retries) on Karaf featuresService.listInstalledFeatures() which has not yet finished installing feature jaas-boot 0.0.0 2018-01-15T14:39:56,154 | INFO | ConfigFeatureListener - ConfigPusher | FeatureConfigPusher | 47 - config-persister-feature-adapter - 0.8.0.SNAPSHOT | Karaf Feature Service has not yet finished installing feature jaas-boot/0.0.0 (retry 0)</pre> </div></div> <p>It is trivial to reproduce this issue, by starting neutron/karaf/target/assembly/bin/karaf and hitting HTTP GET <a href="http://127.0.0.1:8181/controller/nb/v2/neutron/networks" class="external-link" target="_blank" rel="nofollow noopener">http://127.0.0.1:8181/controller/nb/v2/neutron/networks</a>, even just with your web browser, and HTTP BASIC admin/admin, will produce above in the Karaf log.</p> NEUTRON-154

Neutron's Jersey Problem during the big odlparent/yangtools version bump

Bug Highest Resolved Done Robert Varga Michael Vorburger Mon, 15 Jan 2018 14:37:28 +0000 Mon, 22 Jan 2018 19:56:24 +0000 Tue, 16 Jan 2018 18:02:05 +0000 master General 0 6 <p>I got by the "A message body writer..." error by adding:</p> <p> <br/>      &lt;dependency&gt;<br/>         &lt;groupId&gt;com.sun.jersey&lt;/groupId&gt;<br/>         &lt;artifactId&gt;jersey-json&lt;/artifactId&gt;<br/>       &lt;/dependency&gt;<br/>  <br/> to the odl-neutron-northbound-api feature pom based on <a href="https://stackoverflow.com/questions/13108161/a-message-body-writer-for-java-class-not-found" class="external-link" target="_blank" rel="nofollow noopener">https://stackoverflow.com/questions/13108161/a-message-body-writer-for-java-class-not-found</a>  but now I get:<br/>  <br/> 2018-01-13T02:18:44,772 | ERROR | qtp1602373834-139 | ContainerResponse                | 35 - com.sun.jersey.jersey-server - 1.17.0 | Mapped exception to response: 500 (Internal Server Error)<br/> <a href="http://javax.ws.rs/" class="external-link" target="_blank" rel="nofollow noopener">javax.ws.rs</a>.WebApplicationException: javax.xml.bind.JAXBException<br/>  - with linked exception:<br/> <span class="error">&#91;java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory cannot be found by org.opendaylight.neutron.northbound-api_0.10.0.SNAPSHOT&#93;</span><br/>         at com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:159) <span class="error">&#91;34:com.sun.jersey.core:1.17.0&#93;</span><br/>         at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306) <span class="error">&#91;35:com.sun.jersey.jersey-server:1.17.0&#93;</span><br/>  <br/> I got by that by adding com.sun.xml.bind.v2 to Import-Package but now get another failure:<br/>  <br/> java.lang.AssertionError: E2E Tests Failed - Collection not Array<br/>   at org.opendaylight.neutron.e2etest.ITNeutronE2E.test_fetch_collection_response(ITNeutronE2E.java:276)<br/>   at org.opendaylight.neutron.e2etest.ITNeutronE2E.test_fetch_with_one_query_item(ITNeutronE2E.java:296)    <br/>   at org.opendaylight.neutron.e2etest.ITNeutronE2E.test(ITNeutronE2E.java:95)<br/>  <br/>  <br/>  <br/>  </p> <p>This is probably related to <a href="https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8</a> and more specifically to <a href="https://github.com/FasterXML/jackson-jaxrs-providers/issues/22" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/FasterXML/jackson-jaxrs-providers/issues/22</a> .</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/67165/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/67165/</a> from <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt" class="user-hover" rel="skitt">skitt</a> fixes the ConfigPusher (which has nothing at all directly to do with this, but initially seemed to be the reason for the ITNeutronE2E failure, but turned out not to be).</p> <p>The "Collection not Array" is because that jsonElementValue now suddenly is not a JSOn array anymore, so somehow Jersey is behaving differently after the bump; I've added logging to the test and see that it now is this: <tt>"id":"4e8e5957-649f-477b-9e5b-f1f75b21c03c","tenant_id":"9bacb3c5d39d41a79512987f338cf177","name":"net1","admin_state_up":"true","status":"ACTIVE","shared":"false","external":"false","network_type":"flat","segments":<span class="error">&#91;null,null&#93;</span></tt>. I know nothing at all about neutron code, but will try to understand if this is some... mapping annotation that needs to be adjusted?</p> <p>Well, I think this has something to do with MOXyJsonProvider, as that seems to be the thing that is supposed to take care of JSON data. I suspect adding jersey-json changes the provider behavior...</p> <p>Right, so the full response we get froma GET on <a href="http://127.0.0.1:8181/controller/nb/v2/neutron/networks?status=ACTIVE" class="external-link" target="_blank" rel="nofollow noopener">http://127.0.0.1:8181/controller/nb/v2/neutron/networks?status=ACTIVE</a> is:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>{"networks":{"id":"4e8e5957-649f-477b-9e5b-f1f75b21c03c","tenant_id":"9bacb3c5d39d41a79512987f338cf177","name":"net1","admin_state_up":"true","status":"ACTIVE","shared":"false","external":"false","network_type":"flat","segments":[null,null]}}</pre> </div></div> <p>which in the code comes from the class <tt>NeutronNetworksNorthbound</tt> which returns a <tt>NeutronNetworkRequest</tt> (yup, you read that right, that appears to be the Response despite the class being named Request!). Now that <tt>NeutronNetworkRequest</tt> has an <tt>@XmlElement(name = "networks") List&lt;NeutronNetwork&gt;</tt> which due to some change in the JSON serialization with this bump is no longer serialized as a JSON array despite being a <tt>List</tt>. Hm.</p> <p>Today's free fun fact: If we hack an <tt>bulk.add(new NeutronNetwork());</tt> in line 42 of <tt>NeutronNetworkRequest</tt> then it is a JSON array! I'm obviously not suggesting that be the fix, but proving that there is some... wrong optimization in whatever JSON serializer that is being use here that thinks that is a <tt>List</tt> contains only 1 element it can be written out as just JSON object instead of array. Huh.</p> <p>Perhaps the better next step here would be to truly understand how the Big Bump of odlparent and yangtools is causing this change...</p> <p>Yeah, that is codec weirdness/optimization of flattening a collection to a single element? At any rate we should figure out why moxy no longer works at it should.</p> <p>Another thing is the question of whether moxy was ever used at all the breakage actually comes from upgraded jackson <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p> </p> <p>So to sum this up:</p> <ul> <li>in default configuration MOXy does not seem to be used to perform serialization (anymore?, that needs to be confirmed vs. nitrogen)</li> <li>with jersey-json we get serialization working, but it is broken around single-item lists</li> </ul> <p> </p> <p>Hence we either need to get moxy working or replace it with a different JSON provider – for AAA we have the proposal to use GSON at <a href="https://git.opendaylight.org/gerrit/#/c/66056/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/66056/</a>.</p> <p><a href="https://www.eclipse.org/eclipselink/api/2.4/org/eclipse/persistence/jaxb/MarshallerProperties.html#JSON_REDUCE_ANY_ARRAYS" class="external-link" target="_blank" rel="nofollow noopener">https://www.eclipse.org/eclipselink/api/2.4/org/eclipse/persistence/jaxb/MarshallerProperties.html#JSON_REDUCE_ANY_ARRAYS</a> looks interesting... but yes <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> you raise a good point, this seems to be a in complete mess now - I'm myself confused which JSON serializer (codec) is actually used here now. </p> <p>Note the presence of <tt>neutron/northbound-api/src/main/resources/org/opendaylight/controller/networkconfig/neutron/northbound/jaxb.properties</tt>, but that is in a weird package, given that <tt>NeutronNetworkRequest</tt> and Co. are in org.opendaylight.neutron.northbound.api, no? Was this project (neutron) originally using Moxy and by adding jersey-json we've made it use Jackson with (non-Moxy) JAXB instead, causing this (and probably other...) issues? Perhaps instead of fixing JSON array problem in isolation, we should take a step back and understand better what's really going on here. The <tt>jersey-json</tt> dependency may well not actually be the right solution here.</p> <p>But the real question probably is what actually changed in odlparent 3.0.2 compared to 2.0.x to cause the original issue... suggestions, anyone?</p> <p>&gt; Hence we either need to get moxy working or replace it with a different JSON provider – for AAA we have the proposal to use GSON</p> <p>given that the world is broken and a lot of people cannot work on master, I think the priority here should be to get neutron working as it used to before the odlparent bump, which (I think) means understanding what makes Jersey use Moxy and how that broke compared to how it worked before the bump. I'm not clear if that means that jersey-json is a bad idea - we probably need to understand how jersey can be made to work with moxy; how it did before, why it broken, and how to get it back working?</p> <p>Actually replacing it with a different JSON serializer, like GSON, seems safer to do separately later - who knows what other surprises that may lead to.</p> <p>The only related change I am aware of the upgrade from jackson-2.3.2 to jackson-2.8.9...</p> <p>Given that <a href="https://git.opendaylight.org/gerrit/#/c/67168/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/67168/</a> , I am not sure the setup story in this project was completely correct to begin with.</p> <p>So the <tt>NeutronNorthboundRSApplication</tt> configures a <tt>MOXyJsonProvider</tt>, so Neutron clearly originally wanted to use Moxy instead Jackson...</p> <p>jaxb.properties seems to be correct accordking to <a href="https://www.eclipse.org/eclipselink/documentation/2.6/moxy/runtime001.htm#CACFEGHC" class="external-link" target="_blank" rel="nofollow noopener">https://www.eclipse.org/eclipselink/documentation/2.6/moxy/runtime001.htm#CACFEGHC</a> .</p> <p>&gt; Given that <a href="https://git.opendaylight.org/gerrit/#/c/67168/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/67168/</a> , I am not sure the setup story in this project was completely correct to begin with.</p> <p>Interesting but my suspicion would be that's more of a minor oversight leading to that WARN log, but not the real cause of / related to the problem we're chasing here? The MOXyJsonProvider seems to ahave been configured both as class as well as instance, and it looks like if it's configured as instance then one does not need to configure it as class, which makes sense.</p> <p>Let us remove the <tt>jersey-json</tt> dependency again, and try to understand the real cause of the initial <tt>WebApplicationException: com.sun.jersey.api.MessageException</tt> - despite the configuration of the <tt>MOXyJsonProvider</tt> ?</p> <p>One more possibility is that we have a clash on javax.ws.rs(.ext) package and we end up not interpreting MOXyJsonProvider as a correct Provider...</p> <p>Yup, confirmed here:</p> <p>javax.ws.rs.client                                                                                                                                                                                 │ 2.0.1                                  │ 68  │ javax.ws.rs-api<br/> javax.ws.rs.container                                                                                                                                                                              │ 2.0.1                                  │ 68  │ javax.ws.rs-api<br/> javax.ws.rs.core                                                                                                                                                                                   │ 1.1.1                                  │ 34  │ com.sun.jersey.core<br/> javax.ws.rs.core                                                                                                                                                                                   │ 2.0.1                                  │ 68  │ javax.ws.rs-api<br/> javax.ws.rs.ext                                                                                                                                                                                    │ 1.1.1                                  │ 34  │ com.sun.jersey.core<br/> javax.ws.rs.ext                                                                                                                                                                                    │ 2.0.1                                  │ 68  │ javax.ws.rs-api<br/> javax.ws.rs                                                                                                                                                                                        │ 1.1.1                                  │ 34  │ com.sun.jersey.core<br/> javax.ws.rs                                                                                                                                                                                        │ 2.0.1                                  │ 68  │ javax.ws.rs-api</p> <p>&gt; jaxb.properties seems to be correct accordking to <a href="https://www.eclipse.org/eclipselink/documentation/2.6/moxy/runtime001.htm#CACFEGHC" class="external-link" target="_blank" rel="nofollow noopener">https://www.eclipse.org/eclipselink/documentation/2.6/moxy/runtime001.htm#CACFEGHC</a> .</p> <p>I don't think so; note <em>"the same package (directory) in which your model classes reside",</em> and it's in an old org/opendaylight/controller/networkconfig/neutron/northbound/ instead of in org/opendaylight/neutron/northbound/api/ where it should be now... but that's not our problem here, that <tt>javax.ws.rs.WebApplicationException</tt> and <tt>com.sun.jersey.api.MessageException</tt> where Jersey isn't able to find a Codec for MIME application/json most probably hits us and fails long before any JAXB related stuff? And if the MOXyJsonProvider did work, I suspect that probably has the equivalent of <tt>javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory</tt> in jaxb.properties in code instead, so I bet that was just wrong since year and we could probably completely remove that jaxb.properties file, wherever it is, and it will still work (once it uses the MOXyJsonProvider).</p> <p>&gt; One more possibility is that we have a clash on javax.ws.rs(.ext) package and we end up not interpreting MOXyJsonProvider as a correct Provider...<br/> &gt; Yup, confirmed here:</p> <p>Bloody OSGi! So wait, what does this mean? We got the same package in two bundles with different JAX RS versions? And something sets some stupid static in the wrong one of the two? Phew.</p> <p>Looking at moxy's headers, it does not specify a version for its javax.ws.rs import:</p> <p>clipseLink MOXy (176)<br/> ----------------------<br/> Archiver-Version = Plexus Archiver<br/> Build-Jdk = 1.7.0_80<br/> Built-By = genie.eclipselink<br/> Created-By = 1.6.0_21 (Sun Microsystems Inc.)<br/> HK2-Bundle-Name = org.eclipse.persistence:org.eclipse.persistence.moxy<br/> Manifest-Version = 1.0</p> <p>Bundle-ManifestVersion = 2<br/> Bundle-Name = EclipseLink MOXy<br/> Bundle-SymbolicName = org.eclipse.persistence.moxy<br/> Bundle-Vendor = Eclipse.org - EclipseLink Project<br/> Bundle-Version = 2.6.2.v20151217-774c696</p> <p>Export-Package = <br/> org.eclipse.persistence.internal.jaxb;version=2.6.2,<br/> org.eclipse.persistence.internal.jaxb.many;version=2.6.2,<br/> org.eclipse.persistence.jaxb;version=2.6.2,<br/> org.eclipse.persistence.jaxb.attachment;version=2.6.2,<br/> org.eclipse.persistence.jaxb.compiler;version=2.6.2,<br/> org.eclipse.persistence.jaxb.dynamic;version=2.6.2,<br/> org.eclipse.persistence.jaxb.dynamic.metadata;version=2.6.2,<br/> org.eclipse.persistence.jaxb.javamodel;version=2.6.2,<br/> org.eclipse.persistence.jaxb.javamodel.oxm;version=2.6.2,<br/> org.eclipse.persistence.jaxb.javamodel.reflection;version=2.6.2,<br/> org.eclipse.persistence.jaxb.metadata;version=2.6.2,<br/> org.eclipse.persistence.jaxb.rs;version=2.6.2,<br/> org.eclipse.persistence.jaxb.xmlmodel;version=2.6.2<br/> Import-Package = <br/> com.sun.xml.bind;resolution:=optional,<br/> com.sun.xml.bind.annotation;resolution:=optional,<br/> com.sun.xml.bind.api;resolution:=optional,<br/> com.sun.xml.bind.api.impl;resolution:=optional,<br/> com.sun.codemodel;resolution:=optional;version="[2.2.11,3)",<br/> com.sun.xml.xsom;resolution:=optional,<br/> com.sun.xml.xsom.impl;resolution:=optional,<br/> com.sun.xml.xsom.impl.parser;resolution:=optional,<br/> com.sun.tools.xjc;resolution:=optional;version="[2.2.11,3)",<br/> com.sun.tools.xjc.model;resolution:=optional;version="[2.2.11,3)",<br/> com.sun.tools.xjc.outline;resolution:=optional;version="[2.2.11,3)",<br/> javax.activation;resolution:=optional,<br/> javax.json;resolution:=optional,<br/> javax.json.stream;resolution:=optional,<br/> javax.naming;resolution:=optional,<br/> javax.validation;resolution:=optional;version=1.1.0,<br/> javax.validation.constraints;resolution:=optional;version=1.1.0,<br/> javax.validation.groups;resolution:=optional;version=1.1.0,<br/> javax.ws.rs;resolution:=optional,<br/> javax.ws.rs.core;resolution:=optional,<br/> javax.ws.rs.ext;resolution:=optional,</p> <p> </p> <p>Hence I suspect it binds to 2.0.1 and jersey no longer recognizes it.</p> <p>Yup, it is precisely that:</p> <p>karaf@root()&gt; bundle:requirements 176<br/> org.eclipse.persistence.moxy_2.6.2.v20151217-774c696 <span class="error">&#91;176&#93;</span> requires:<br/> --------------------------------------------------------------------<br/> osgi.wiring.package; (osgi.wiring.package=javax.activation) resolved by:<br/>    osgi.wiring.package; javax.activation 1.1.0 from org.eclipse.osgi_3.11.3.v20170209-1843 <span class="error">&#91;0&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.json) resolved by:<br/>    osgi.wiring.package; javax.json 1.0.0 from org.glassfish.javax.json_1.0.4 <span class="error">&#91;179&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.json.stream) resolved by:<br/>    osgi.wiring.package; javax.json.stream 1.0.0 from org.glassfish.javax.json_1.0.4 <span class="error">&#91;179&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.naming) resolved by:<br/>    osgi.wiring.package; javax.naming 0.0.0 from org.eclipse.osgi_3.11.3.v20170209-1843 <span class="error">&#91;0&#93;</span><br/> osgi.wiring.package; (&amp;(osgi.wiring.package=javax.validation)(version&gt;=1.1.0)) resolved by:<br/>    osgi.wiring.package; javax.validation 1.1.0.Final from javax.validation.api_1.1.0.Final <span class="error">&#91;66&#93;</span><br/> osgi.wiring.package; (&amp;(osgi.wiring.package=javax.validation.constraints)(version&gt;=1.1.0)) resolved by:<br/>    osgi.wiring.package; javax.validation.constraints 1.1.0.Final from javax.validation.api_1.1.0.Final <span class="error">&#91;66&#93;</span><br/> osgi.wiring.package; (&amp;(osgi.wiring.package=javax.validation.groups)(version&gt;=1.1.0)) resolved by:<br/>    osgi.wiring.package; javax.validation.groups 1.1.0.Final from javax.validation.api_1.1.0.Final <span class="error">&#91;66&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.ws.rs) resolved by:<br/>    osgi.wiring.package; javax.ws.rs 2.0.1 from javax.ws.rs-api_2.0.1 <span class="error">&#91;68&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.ws.rs.core) resolved by:<br/>    osgi.wiring.package; javax.ws.rs.core 2.0.1 from javax.ws.rs-api_2.0.1 <span class="error">&#91;68&#93;</span><br/> osgi.wiring.package; (osgi.wiring.package=javax.ws.rs.ext) resolved by:<br/>    osgi.wiring.package; javax.ws.rs.ext 2.0.1 from javax.ws.rs-api_2.0.1 <span class="error">&#91;68&#93;</span></p> <p>Looking at moxy 2.7.1, it will explicitly bind to version 2.0.1, so upgrading it will not solve our problem. Looking at jersey, 1.19.4 no longer packages javax.ws.rs, so that may be path out of this. Alternatively we wrap moxy and force it to resolve javax.ws.rs to 1.1.x.</p> <p>Confirmed to be present.</p> <p>&gt; Looking at moxy 2.7.1, it will explicitly bind to version 2.0.1, </p> <p>was just looking at that as well... we're apparently on moxy 2.6.2, so attempting a bump to 2.7.1 seems reasonable?</p> <p>So if we want to avoid surprises down the road on the next round of bumps and get this over with, that would be the right thing to do here, IMHO...</p> <p>&gt; so upgrading it will not solve our problem. Looking at jersey, 1.19.4 no longer packages javax.ws.rs, so that may be path out of this. </p> <p>that sounds like worth a try?</p> <p>&gt; Alternatively we wrap moxy and force it to resolve javax.ws.rs to 1.1.x.</p> <p>yeah, short term alternative; but then we have to remember to remove this work-around again sooner or later, no?</p> <p>Yeah, so to unblock netvirt I propose to just munge moxy into northbound-api (yeah, it is ugly) and discuss the jersey situation on the kernel projects call. At this point, everything for the upgrade to 2.x should be ready from odlparent and is really all about aaa+netconf and other downstreams...</p> <p>This just shows how technical debt can explode at the worst possible of times.</p> <p>As for jersey-1.19 – is probably the middle ground here, but given how much non-progress we have made over the years in moving from 1.17 I would strongly suggest biting the bullet (again) and cleaning the mess once and hopefully for ever.</p> <p>Just catching up - had to step out for a while. Nice find Robert and Michael. </p> <p><a href="https://git.opendaylight.org/gerrit/#/c/66509/8" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/66509/8</a></p> <p>Thanks for working hard during weekend.<br/> For Florine, let's fix it right uniformly among projects.</p> <p>FTR: <a href="https://jira.opendaylight.org/browse/NETCONF-502" title="API docs does not work after upstream version bump" class="issue-link" data-issue-key="NETCONF-502"><del>NETCONF-502</del></a> is hitting something very similar...</p> Relates NEUTRON-124 NETCONF-502 Development Rank 0|i039h3: