Allow for the creation and management of organization records (UXPROD-1139)

[MODVEND-71] mod-vendors build fails in Jenkins Created: 07/Jan/19  Updated: 03/Jan/20  Resolved: 27/Aug/19

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: File Address.java.fail     File Address.java.good     File Address_.java.fail     File Address_.java.good    
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 MODVEND-66 Closed fails in Jenkins but not in other environments. Specifically, the unit tests for AddressTest, UrlTest, VendorAddressTest and VendorUrlTest are failing, and the errors seem to indicate that the models being used during the test aren't as expected. (ie error says Address doesn't have a "addressLine1" field).



 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
Address.java
Url.java
Url_.java

Sobha Duvvuri had reported a similar issue some time ago.

I think RMB, since it dynamically generates classes and class names based on schemas, in my case multiple schemas have “attributes” in them and each of them could be inherently pointing to a different .json file

RMB when it generates it probably does not follow one particular order and appends ‘_’ to class names with same schema field name

so in my case, I have ‘Attributes’ defined in three different places and RMB when it is generating POJOs, is generating Attributes.java, Attributes_.java and Attributes__.java probably

what each file contains on my machine need not necessarily be the same as what is being generated on Jenkins machine

and clearly its different - need to figure out if there is way to mention to RMB (POJO generator) to be consistent / specify a POJO name that we want it to be instead of appending ‘_’ to the file names and generating many files with those names

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 Address.java.good Address.java.fail Address_.java.fail

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. MODVEND-63 Closed

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

Generated at Thu Feb 08 23:15:08 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.