[NETCONF-212] API Doc Explorer broken due to index.html:1 Uncaught SyntaxError: Unexpected token } in JSON at position 6398 index.html:1 Uncaught SyntaxError: Unexpected token } in JSON at position 1234 Created: 30/May/16 Updated: 15/Mar/19 Resolved: 17/Oct/16 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | restconf-nb |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Michael Vorburger | Assignee: | Michael Vorburger |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Attachments: |
|
| External issue ID: | 5980 |
| Description |
|
When I try to use the http://localhost:8181/apidoc/explorer/index.html API Doc Explorer of the basic Hello example (https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype) right now, then it appears to be broken. It used to work for me (before?) last week, but right now does not anymore. The home page actually does still show up, but "Show/Hide", "List Operations" and "Expand Operations" all do not work. Chrome's Console shows: "index.html:1 Uncaught SyntaxError: Unexpected token } in JSON at position ..." and under Firefox Console has "SyntaxError: JSON.parse: expected ':' after property name in object at line 1 column 584 of the JSON data swagger.js:308:26" The root cause is that the JSON returned by netconf/restconf/sal-rest-docgen is invalid (in some case/s). Specifically, I'm seeing the following pattern, when debugging through JS in browser but also with that "Raw" link available on every line on the Web UI: {"apiVersion":"1.0.0","swaggerVersion":"1.2", ..., "models"}" Note that "models" is a JSON key with the ':' and value missing!
|
| Comments |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
Looking into the code, we see org.opendaylight.netconf.sal.rest.doc.swagger.ApiDeclaration has a JSONObject models - and it would appear that, under some circumstances, Jackson serializes this incorrectly... Some Jackson bug? netconf/restconf/sal-rest-docgen/pom.xml already is on on the latest version already (2.7.4), via odl-parent. But in hello/karaf/target/assembly/system/com/fasterxml/jackson/core/jackson-databind/ there is a 2.3.2 as well - how can I see which one of these two Karaf is using for this bundle at run-time? Attached is the output of "feature:list -i" of the Hello example. |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
Attachment feature-list-i.txt has been added with description: feature:list -i |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
> in hello/karaf/target/assembly/system/com/fasterxml/jackson/core/jackson-databind/ there is a 2.3.2 as well - how can I see which one of these two Karaf is using for this bundle at run-time? With the (generated) OSGi MANIFEST.MF of sal-rest-docgen-1.4.0-SNAPSHOT.jar specifying Import-Package: com.fasterxml.jackson.databind;version="[2.7,3)" etc. this seems fine, and unlikely the reason. |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
Hm.. I've just noticed that odlparent merged "Upgrade Jackson 2.3.2 -> 2.7.4" 7 days ago... perhaps because of that? I'll try to locally revert and see if that helps. I've asked on http://stackoverflow.com/questions/37528039/jackson-missing-colon-and-value-in-json-after-key to learn more. |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
> odlparent merged "Upgrade Jackson 2.3.2 -> 2.7.4" 7 days ago... perhaps because of that? I'll try to locally revert and see if that helps. Yes, that is the root cause! If I locally revert commit 2061aa51982fa82d3414d8f03729819b785ff296 in odl-parent, and mvn install odlparent, and then mvn install both netconf/restconf/sal-rest-docgen as well as netconf/features/restconf (this last step is important, otherwise you get pretty funky bundle startup problems "Caused by: java.lang.VerifyError: Bad type on operand stack", then http://localhost:8181/apidoc/explorer/index.html works again for me. |
| Comment by Michael Vorburger [ 30/May/16 ] |
|
BTW: What's also very interesting is that no test caught this problem... it would be good to include writing a test for future non-regression this as part of the final resolution of this issue. |
| Comment by Michael Vorburger [ 02/Jun/16 ] |
|
Taking this bug assigned to me to write a non-regression test for this problem.
|
| Comment by Miroslav Kovac [ 17/Oct/16 ] |
|
Is this bug still a problem? I can`t seem to replicate it. Seems like it was already fixed. Could you please check it if it works for you too. I checked it on firefox and chrome - both worked fine. |
| Comment by Michael Vorburger [ 17/Oct/16 ] |
|
> I can`t seem to replicate it. Seems like it was already fixed. Could you please check it if it works for you too. I checked it on firefox and chrome - both worked fine. No time right now, as focusing on something else currently, BUT I believe this was one of the very first bug I had filed on ODL, just when I started - it's very possible that this was fixed meanwhile, and as you have already checked out again, let us just close it - I've done it. |