Search code examples
javaspringspring-bootgeodespring-data-gemfire

How to start Spring Boot app without depending on Pivotal GemFire cache

I have a Spring Boot app with a Pivotal GemFire ClientCache instance configured and its corresponding domain objects. I am also using Spring Boot Test for unit testing. For every test case execution, either through class or Maven build, Spring ApplicationContext fails to load if the GemFire cache is down.

How to start Spring Boot application without depending on GemFire cache?

Solution

  • I am not sure I follow exactly what you mean by...

    "For every test case execution, either through class or Maven build, Spring ApplicationContext fails to load if the GemFire cache is down."

    Are you recreating the ClientCache instance for each test case (method) in your test class?

    If so, then this can be tricky to do since even after calling ClientCache.close(), GemFire may not have completely "closed" and released all the resources used by the ClientCache instance. However, usually that does not prevent the Spring ApplicationContext from being recreated on subsequent test case executions. It usually just leads to subsequent test failures since the ClientCache instance is dirty, or stale, retaining old state from the previous (or last) test case execution.

    Are you also using Spring's @DirtiesContext on your test case method as well?

    Usually, it is wise to cycle the ApplicationContext and GemFire cache instance (e.g. ClientCache) per test class, where each test case method in the test class will use the same ApplicationContext and ClientCache instance; this is the most ideal.

    With that, I have 2 things to share with you:

    1. First, have a look at the new Spring Boot for Apache Geode/Pivotal GemFire project. Documentation is here. I announced the availability of this project nearly a month ago now. This project takes a "client-side" perspective to building Spring Boot applications with Pivotal GemFire. That is, it gives you an auto-configured ClientCache instance by default.

    2. Specifically, have a look at Spring Boot for Pivotal GemFire's test suite, beginning here. Nearly all these test classes use a ClientCache instance and test various aspects of Pivotal GemFire, such as CQ's or Security, etc.

    3. In certain test classes, I used a "mock" ClientCache instance (for example, this test class, and this test configuration in particular). However, in many other cases, I used a live GemFire ClientCache instance, for example or this test class, which is interesting since this test class even launches a server for the ClientCache instance (the test itself) to connect to.

    4. All the test coordination logic in Spring Boot for Apache Geode/Pivotal GemFire is provided by another new project, Spring Test for Apache Geode/Pivotal GemFire. Unfortunately, Spring Test for Apache Geode/Pivotal GemFire is still largely a WIP, so does not have documentation yet. However, I have used this new test project extensively to test Spring Boot for Apache Geode/Pivotal GemFire. You will see its presence in the extension classes, like ForkingClientServerIntegrationTestsSupport, and so on.

    In summary, use the new Spring Boot for Pivotal GemFire & Spring Test for Pivotal GemFire project as your guide for writing more effective Unit and Integration tests.

    Finally, if you have an example GitHub repository reproducing your problem, I can help point you in the right direction.

    Hope this helps!

    Regards, John