eclipse / lyo

Eclipse Lyo, a Java SDK for OSLC-based tool integration

Home Page:https://oslc.github.io/developing-oslc-applications/eclipse_lyo/eclipse-lyo.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support handling of a typed ResponseBuilder.entity reponse

berezovskyi opened this issue · comments

When we want to return a Response instead of a Collection<AbstractResource>, we need to use ResponseBuilder.entity() method to pass the entity. The generic signature is not preserved this way. The suggested way to solve this is to wrap the entity with a GenericEntity.

Unfortunately, this changes the type of the generic arguments as seen by JAX-RS Providers from Class to TypeVariable. This PR enables RDF-based providers to handle both kinds. It also adds error log statements for the JSON Provider that the TypeVariable support is missing.

PR #286 added support for this and was merged to master to be able to test it on OSLC servers that use Lyo SNAPSHOT in their nightly builds. This issue tracks outstanding work items.

  • Add a CHANGELOG entry
  • Add unit/integration tests
  • Equalize writability logic between RDF and JSON providers (see #286 (comment))
  • Test on RefImpl

A basic servlet-based integration test was added in #288.

The test matrix should cover:

  • @OslcQueryCapability resource method annotation
  • @OslcNotQueryResult Lyo POJO class annotation
  • Use of List vs Array collection types by the resource.
  • Use of a Response resource method return type (with the use of GenericType trick) vs returning List/Array directly.
  • Set of Providers registered (RDF JSON has three "presets": default, simple, and updated)

Also, the tests should be done as similar as possible on the proper RDF (Jena) and "OSLC RDF JSON" providers. This may require either merging #284 first, so that the common abstract classes can be shared, or having this PR only test JSON providers and extracting the code later when #284 is merged.

For the test matrix, we should use JUnit 5 @ArgumentSource (simpler @MethodSource and @ValueSource likely won't be enough). On the resource side, test matrix items would result in simply duplicating a JAX-RS method with needed variations, on the test side we will mostly use the parameters supplied via @ArgumentSource (except for the provider set "profile", which requires different test classes to be set up). We expect the test matrix to have the following values for whether the response is a QC ResponseInfo:

@OslcQueryCapability@OslcQueryCapability
@OslcNotQueryResult
@OslcNotQueryResult

The results should not vary for the rest of the test matrix elements.