Allow for the creation and management of organization records
(UXPROD-1139)
|
|
| Status: | Closed |
| Project: | mod-vendors |
| Components: | None |
| Affects versions: | None |
| Fix versions: | 2.0.2 | Parent: | Allow for the creation and management of organization records |
| Type: | Bug | Priority: | P3 |
| Reporter: | John Malconian | Assignee: | Craig McNally |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | back-end, ci | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
| Sprint: | ACQ Sprint 56 |
| Development Team: | Core: Platform |
| Tester Assignee: | Craig McNally |
| Epic Link: | Allow for the creation and management of organization records |
| Description |
|
Build for branch
|
| Comments |
| Comment by John Malconian [ 07/Jan/19 ] |
|
Have verified this. I can get a successful build when running the build manually in the Jenkins build environment, but it still fails when run invoked by Jenkins. |
| Comment by John Malconian [ 07/Jan/19 ] |
|
Example error from Jenkins: 13:35:27 INFO LogUtil 127.0.0.1:46844 POST /vendor_address null HTTP_1_1 422 466 -1 tid=null Unprocessable Entity {"errors":[{"message":"Unrecognized field \"addressLine1\" (class org.folio.rest.jaxrs.model.Address), not marked as ignorable (4 known properties: , \"language\", \"id\", \"address\", \"categories\"])\n at [Source: java.io.StringReader@358bf0c8; line: 3, column: 26] (through reference chain: org.folio.rest.jaxrs.model.VendorAddress[\"address\"]->org.folio.rest.jaxrs.model.Address[\"addressLine1\"])","type":"1","code":"-1","parameters":[{"key":"","value":""}]}]}
HTTP/1.1 422 Unprocessable Entity
Content-type: application/json
Transfer-Encoding: chunked
{
"errors": [
{
"message": "Unrecognized field \"addressLine1\" (class org.folio.rest.jaxrs.model.Address), not marked as ignorable (4 known properties: , \"language\", \"id\", \"address\", \"categories\"])\n at [Source: java.io.StringReader@358bf0c8; line: 3, column: 26] (through reference chain: org.folio.rest.jaxrs.model.VendorAddress[\"address\"]->org.folio.rest.jaxrs.model.Address[\"addressLine1\"])",
"type": "1",
"code": "-1",
"parameters": [
{
"key": "",
"value": ""
}
]
}
]
}
I'm wondering if the issue is how RMB is generating classes for the schemas due to some kind of overlap. I notice that in target/generated-sources/raml-jaxrs/org/folio/rest/jaxrs/model, the following files are generated: Address_.java Sobha Duvvuri had reported a similar issue some time ago.
|
| Comment by John Malconian [ 07/Jan/19 ] |
|
Yeah, something similar is happening in this case. I've attached the generated classes for the source files, Address_.java and Address.java, for working builds and failed builds. For working builds, Address.java.good and Address_.java.good are virtually identical. However, for failed builds, Address.java.fail and Address_.java.fail are very different. Seem to be totally different schemas between the two. I suspect that something similar occurs with the generated Url.java and Url_.java classes. I think what's maybe needed here is some schema clean up? Sobha Duvvuri Is there anything else you can think of that should be done to resolve this? Also CC'ing Adam Dickmeiss and assigning back to John Komick. Address_.java.good |
| Comment by David Crossley [ 07/Jan/19 ] |
|
Although it may be a big job, upgrading to RMB 23+ and RAML 1.0 might side-step this.
|
| Comment by John Malconian [ 08/Jan/19 ] |
|
right, David Crossley. That's probably the way to go. |
| Comment by John Malconian [ 08/Jan/19 ] |
|
John Komick I'm going to re-enable merging restrictions for this repo. This is a legitimate code issue - not a CI issue. |
| Comment by John Komick [ 28/Jan/19 ] |
|
The cause of these issues have been resolved as part of https://folio-org.atlassian.net/browse/MODVEND-72 which have been merged into the mod-vendors master branch and deployed to folio-test. |
| Comment by Sobha Duvvuri [ 06/Mar/19 ] |
|
John Malconian: Sorry, I was out on maternity leave last couple of months and just got back this week. The way we resolved this issue in mod-kb-ebsco-java is by providing a "javaType" in the json schema which is essentially a name for the generated class that we can provide. This prevents the problem of multiple classes having the same name and underscores being appended. More reference here: https://github.com/joelittlejohn/jsonschema2pojo/wiki/Reference |