Service Registry cannot unmarhsall data object query

Data Services
1

I am attempting to issue a DataObjectQuery to a service registry via a DataObjectServiceRestClient. The request makes it to the service and I see these error logs in my service-registry:

15:27:07.301 [qtp416682209-36] WARN  c.l.l.e.m.LeafExceptionMapper - There has been an exception mapped to a Internal Server Error response
com.fasterxml.jackson.databind.JsonMappingException: Expecting START_ARRAY, found VALUE_FALSE
 at [Source: (org.eclipse.jetty.server.HttpInputOverHTTP); line: 1, column: 26] (through reference chain: com.leidos.leaf.beans.query.DataObjectQuery["filters"])

The DataObjectQuery is as follows: (Note that it was copied verbatim from the Service Registry LEAF Knowledge Base Sign in to LEAF)

DataObjectQuery.newBuilder().withFilters(Filters.types(LeafServiceMetadataConstants.TYPE)).build()

Im not sure why the filters are not able to be deserialized. Any help would be greate.

2

How did you make the JAX-RS Client object that you use to eventually construct the DataObjectServiceRestClient? I would suggest using

// This is using a LEAF-provided util class in framework-services-rest-easy
Client client = RestClientUtils.makeRestClient();

which registers LEAF’s JsonObjectMapperProvider with the Client object for you.

If not, when you make the Client, assuming you’re using Resteasy, you need to do something like this:

Client client = new ResteasyClientBuilderImpl()
        ... // other configuration
        .register(new JsonObjectMapperProvider())
        .build();

where that register line will make it so you’re client maps Java objects to JSON using LEAF’s JsonObjectMapper.

If not using Resteasy, I’m sure there’s an equivalent way to do that, but I don’t know it off the top of my head.

3

Yes, using RestClientUtils.makeWebTarget(string url) worked for me. Thanks!

1 Like
4

@mark.a.alvaro your suggestions worked, but now I am getting another error in regards to processing. See below:

"class": "com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException",
        "propertyName": "propsToOverrideCsv",
        "messageSuffix": " (30 known properties: \"preferredPixelWidth\", \"neededForAuthorization\", \"active\", \"defaultLayoutIndex\", \"propName\", \"foreignFieldIdentifier\", \"stringUiComponentType\", \"defaultListed\", \"required\", \"defaultColumnNumber\", \"caseStyle\", \"foreignTargetJobName\", \"longName\", \"fieldLevelEditAttribute\", \"maxLength\", \"fieldLevelViewAttribute\", \"defaultValue\", \"indexed\", \"columnViewable\", \"unalterable\", \"validationErrorMessage\", \"large\", \"aliasPropName\", \"helpText\", \"loggableAttribute\", \"shortName\", \"tagsCsv\", \"format\", \"userEditable\", \"propsToOverride\"])",
        "referringClass": "com.leidos.leaf.beans.metadata.field.StringFieldMetadata"

I thought that maybe the version of the service registry was the issue… My data service is on 3.3 and service registry was on 3.4, so I redeployed the helm release on an earlier version and still get this error. Perhaps the JsonObjectMapperProvider in the rest client utils does not understand the propsToOverrideCsv?

5

Interesting. Our JsonObjectMapper by default doesn’t fail on unknown props, so I’m not totally sure where that error could be coming from. Are you seeing that on the client or in the server logs? If in the client, are you customizing the JsonObjectMapper’s MAPPER_INSTANCE?

6

Also I double checked and

  "propsToOverrideCsv" : "longName,shortName",

is legal in 3.5 at least, and I’m not aware of that attribute changing at all in 3.x.

7

Im seeing it client side. Here is the code for the JsonObjectMapperProvider:

MetadataServiceRestClient.newBuilder(RestClientUtils.makeWebTarget(endpoint + context)).build()

Where endpoint and context are variables passed as parameters.

8

Just to be clear: nowhere else in your project are you configuring the JsonObjectMapper or JsonObjectMapper.MAPPER_INSTANCE or JsonObjectMapperProvider, correct? It’s mutable, so anywhere in your code that fail on unknown attrs could be applied, and I highly doubt we support that.

9

I cannot find anywhere in this project where we customize the mapper or provider, no… I’ve pinged the rest of my team to be sure.

10

There was an issue with a separate data object service rest client where we were using Client.newBuilder(…).target(…) to construct the client for the rest service. That, for some reason, was causing issues with other clients constructed using RestClientUtils.makeClient(). So if anybody has a similar issue, perhaps search the project and ensure you are using RestClientUtils to construct a base client and then calling target(…) on that.