2
votes

I'm having a weird issue in my Spring Boot application (2.2.6.RELEASE) using Spring Data Rest (3.2.6.RELEASE). From time to time my repositories are not exposed via rest. This is happening with the exact same version (same jar) of my application using the exact same configuration.

There are 4 @RepositoryRestResource's and when it's working, the root resource exposes this:

{
    "_links": {
        "entity-a": {
            "href": "http://localhost:8080/api/entity-a{?projection}",
            "templated": true
        },
        "entity-b": {
            "href": "http://localhost:8080/api/entity-b"
        },
        "entity-c": {
            "href": "http://localhost:8080/api/entity-c{?page,size,sort,projection}",
            "templated": true
        },
        "entity-d": {
            "href": "http://localhost:8080/api/entity-d"
        },
        "profile": {
            "href": "http://localhost:8080/api/profile"
        }
    }
}

and when it's not working it returns:

{
    "_links": {
        "profile": {
            "href": "http://localhost:8080/api/profile"
        }
    }
}

Some additional findings:

  • The JPA component scan is working in both scenarios
  • The repositories themselves are working cause in both scenarios, custom controllers using these repo's work fine
  • Enabling debug logging for org.springframework.data produces the exact same output in both scenarios
  • Comparing responses from actuator endpoints doesn't show any noticeable difference
  • Repository detection strategy is set to RepositoryDetectionStrategies.ANNOTATED explicitly
  • I cannot reproduce it in a SSCE
  • Module has been upgraded from Spring Boot 1.5.18, the issue started happening after the upgrade.

Has anybody else experienced this issue before? What might be causing this? Or some pointers on how I can further analyse this problem?

1
seems like there is an issue with the RepositoryRestResource, when you are saying in both scenarios you mean this breakes after a restart? or it can happen runtime also? A good option is to track and debug the piece of code that creates the mapping against any discovered entity / service, to cross check that you dont have a library mismatch there - AntJavaDev
@AntJavaDev Yes, it is a startup/context loading problem, it never changes at runtime. I tried tracing/debugging as much as possible, but it seems to me that it comes down to org.springframework.data.repository.core.support.RepositoryFactoryInformation's being found and that should be the case for all four repositories in both scenarios. Library mismatch/conflict came to my mind too, but it seems to me that only spring data related dependencies are involved here, all managed via starter dependencies without any specific versions. - wjans
hmm pretty awkward, are we sure this is not any short type of proxy caching / response caching ? i mean if you dont restart the whole app, it wont expose the 4 api calls, no matter what? What about if you are adding another custom one? are the new classes being placed in a different pkg / jar? - AntJavaDev
No, it remains the same for hours (days even). The repo's are in the same package within the module itself (subpackage of the configured base package for the @EntityScan). - wjans
most probably a transient dependency doing the trick, you suggest that turning back to boot parent 1.5.18, wont create that issue ? - AntJavaDev

1 Answers

3
votes

Sounds like you're running into DATAREST-1502 which has been fixed in 3.2.7 and newer.