Closed BryceStevenWilley closed 1 week ago
Ah, does appear to be a lot of sorting changes. Wonder why the ordering changed..? 🤔 Changes look pretty good to me.
I did notice that the WebServiceClient WSDL locations changed from classpath to file resources. Is that intentional?
Example of New Value:
@WebServiceClient(name = "EfmUserService",
wsdlLocation = "file:illinois-EFMUserServiceSingle.svc.wsdl",
targetNamespace = "urn:tyler:efm:services")
Previously:
wsdlLocation = "classpath:wsdl/EFMUserServiceSingle.svc.wsdl",
Ah, does appear to be a lot of sorting changes. Wonder why the ordering changed..? 🤔
:shrug: I think it has something to do with how wsdl2java works, I assume it's using Sets or something unsorted internally during code generation. It'd be so nice if that wasn't an issue, but eh.
I did notice that the WebServiceClient WSDL locations changed from classpath to file resources. Is that intentional?
That's not! That is another wsdl2java makes for you, and we have to manually revert.
Update Schema to 2024.3.
Originally, I was trying to fix this error
However, I got stuck trying to figure it out. Then, another Schema related error started happening in production (
unexpected element (uri:"urn:tyler:ecf:extensions:Common", local:"ServiceConsentEmail")
), which forced me to make more progress here.Eventually realized that the GetStatus error has to be on Tyler's side; when we call them with the
Status
attribute inUserType
, we get an error (even though it's in the Schema they give us), but when we manually remove it from the client-side schema and Java code, theUserType
they return has aStatus
in it, which the client errors on! I've reached out to them for them to fix the issue, but it seems to be a stage only thing. I turned off that check in the integration test, and every thing else works fine.Going to merge this.