[jira] [Resolved] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests

["Kirk Lund (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kirk Lund resolved GEODE-5644.
------------------------------
    Fix Version/s: 1.12.0
       Resolution: Fixed

> New DistributedReference JUnit rule for DistributedTests
> --------------------------------------------------------
>
>                 Key: GEODE-5644
>                 URL: https://issues.apache.org/jira/browse/GEODE-5644
>             Project: Geode
>          Issue Type: Wish
>          Components: tests
>            Reporter: Kirk Lund
>            Assignee: Kirk Lund
>            Priority: Major
>             Fix For: 1.12.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> I'd like to add a new DistributedReference JUnit rule for DistributedTests which would be used similar to an AtomicReference but with a reference that is useable within every DUnit VM.
> The idea is that this would allow us to define something like:
> {noformat}
> @Rule
> public DistributedReference<Cache> cacheReference = new DistributedReference<>();
> @Before
> public void setUp() {
>   getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
> }
> @After
> public void tearDown() {
>   getVM(0).invoke(() -> cacheReference.get().close());
> }
> {noformat}
> Each DUnit VM would have its own instance of Cache (or other type) available to set and get with this rule.
> This enables us to the Geode APIs directly within a test without depending on more complex custom rules like CacheRule or ClusterStarterRule. This would make tests that use it more directly dependent on the User APIs and force us to become more aware of of the shortcomings of that API including its defaults. If the Geode User APIs for creating and closing Cache is so difficult or verbose to use or has the wrong defaults, then this will encourage us to fix the Geode User API instead of hiding it behind complex custom rules that act as an API Adapter layer.
> We could also consider adding support for java.io.Closeable since resources such as Cache implement Closeable. This would then obviate the need to implement @After in most cases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)