I’m trying to use the lyo library to query for some workitems. The result has multiple pages, so I’m trying to fetch the next page from the OslcQueryResult using
OslcQuery query = new OslcQuery(oslcClient, queryCapability, pageSize, queryParams);
OslcQueryResult result = query.submit();
//fetch the workitems from the first page
//...
if (result.hasNext()) { //trying to fetch the next page
result = result.next();
}
However, the hasNext() method returns always false even though I have multiple pages:
I tested the same sample code with a QM query and in that case it works, I am able to fetch the nextPage URL, because the “ResponseInfo” tag is unique:
Isn’t it odd that your response contains multiple responseInfo entries?
I cannot see the overall structure of the response, but is there some hierarchy of these resources? Can you somehow identify yourself which ResponseInfo resource is correct?
We might need to modify the logic to (somehow) identify this topLevel resource.
The rest “ResponseInfo” resources are mostly details about the “rtc_cm:subscribers” field and another custom attribute field. For subscribers field there’s one individual “ResourceInfo” entry for each work item which has subscribers:
One more thing, the initial query was made to return all the work item attributes (oslc.select=*), if I somehow try to exclude the “rtc_cm:subscribers” (and the other problematic custom attribute) then there’s a single “ResponseInfo” and the nextPage can be fetched (e.g.: I tested for oslc.select=dcterms:title). But the problem here is that we want to fetch all the details for each work item. We could maybe make a workaround and try to exclude the problematic ones, but I think it’s kinda hard to build the oslc.select for this case and it still does not guarantee that the same issue cannot happen for other attributes in the future.
@anamr please try feat: handle multiple ResponseInfo obj in Query response by berezovskyi · Pull Request #606 · eclipse/lyo · GitHub and tell us if it works for you (PR review comments would be welcome too!). I don’t have the full response from Jazz to write a test for it, so we will need your help in testing before we merge. Sadly, the spec is not clear enough in whether one ResponseInfo, in presence of multiple of them in the response, can be assumed to have the same URI as the query URI.
I looked in the pull request, it looks good, but I don’t know how I can test it on my side.
How can we reproduce the response in the EWM sample? Somehow we should alter the OslcQueryResult to contain more than one “ResourceInfo” and I’m not sure how to do that.
If you could prepare a new alpha version containing this change, it would be very easy for us to test it by simply changing the dependency version. We have Jazz test environments with both Jazz ver. 7.0.2 and 7.0.3.
We try to verify every PR before merging it. Releasing an alpha would require us to merge and even push untested code to Maven Central.
Could you please instead clone the Lyo git repo, switch to the pull request branch b605-multiple-responseinfos, and run mvn clean install in the root dir of the repo? This will install locally into your .m2 folder that you can test by changing Lyo version in your project to 6.0.0-SNAPSHOT.
Sorry for the delayed response, I got carried away with some other stuff.
I tested the pull request and Jad is somehow right, the queryURL does not match exactly the nextPageURL. The nextPageURL has some additional parameters at the end:
Additionally, I just wanted to point out that with this new version, I also had to fix some imports (because of the jakarta upgrade - package name has changed from ‘javax’ to ‘jakarta’) and I had to upgrade the org.glassfish.jersey dependencies. Luckily, I looked in your pom.xml file and I could figure out the correct versions.
I believe ResponseInfo was only intended to be used for resource paging and there was intended to be only one in a response that had paging support. At least that’s my reading of OSLC core paging and OSLC Query. Subscribers and other related resources would typically be part of the RDF entity response body.
