Hello Everyone,
I’m trying to fetch multiple Test cases, specifying ‘in’ clause with the test case IDs (shortId).
The where clause string I’m setting is “oslc:shortId in [100,101]”.
While setting the where clause in a ‘OslcQueryParameters’, the string is encoded to “oslc%3AshortId+in+%5B463557%2C463558%5D” (The spaces have been replaced with ‘+’ and [,],’,’ are also replaced with corresponding hex code.).
When this queryparameter is passed to OslcQuery, the (JerseyWebTarget) queryResource’s targetURI is formed by encoding the where clause again, which results in ‘+’ replaced with ‘%2B’ hex code. The value is oslc.where=oslc%3AshortId%2Bin%2B%5B463563%2C463564%5D.
When the URL formed with this double encoding is called, then, I’m getting ’ [AQXCM5002E The query was not run for this query] error. When I run with the “oslc%3AshortId+in+%5B463557%2C463558%5D” in where clause, then, the results are returned correctly.
Could you please let me know what I’m doing wrong? How can I stop this double encoding?
I’m connecting to the IBM’s RQM server and I’m using the below code:
String queryCapability = getOslcClient().lookupQueryCapability(getServiceProviderUrl(), OSLCConstants.OSLC_QM_V2, OSLCConstants.QM_TEST_CASE_QUERY);
OslcQueryParameters queryParams = new OslcQueryParameters();
StringJoiner sj = new StringJoiner( “,”);
requirementLinks.keySet().forEach(id -> {
sj.add(id);
});
queryParams.setWhere(OslcConstants.OSLC_CORE_NAMESPACE_PREFIX + “:shortId in [” + sj.toString() + “]”);
OslcQuery query = new OslcQuery(getOslcClient(), queryCapability, queryParams);
OslcQueryResult result = query.submit();
Are you encoding the where clause before setting it in ‘OslcQueryParameters’?
Try not to do that and see if it helps.
I would assume (but it can be wrong) that OSLCQuery is taking care of any necessary encoding before the query is submitted.
Have you tried debugging your request down into the OSLCClient library?
Actually, I’m not encoding the where clause before setting in the ‘OslcQueryParameters’.
I think I have not explained myself, clearer.
I did a little debugging and below is the following flow, which encodes the where clause twice.
When I call API OslcQueryParameters.setWhere(“oslc:shortId in [100,101]”), the API in turn calls the private OslcQueryParameters.encodeQueryParams(String), which converts the given string to “oslc%3AshortId+in+%5B463557%2C463558%5D”.
When the constructor OslcQuery.OslcQuery(OslcClient, String, OslcQueryParameters) is called with the above formed query parameter, ‘OslcQuery.queryUrl’ attribute is formed by calling the OslcQuery.getQueryUrl() API. which in turn calls the org.glassfish.jersey.uri.internal.JerseyUriBuilder.build(Object…) API, which internally calls the org.glassfish.jersey.uri.internal.JerseyUriBuilder._build(boolean encode, boolean encodeSlashInPath, Object…) API, which again encodes the where clause.
Looks like a bug then! It’s also bizzar that the constructor doesn’t call encoding. So one way of avoiding this problem is to construct your OslcQueryParameters, instead of calling setWhere.