there is a slight risk that somehow something has changed the
implementation details of jclouds such that the executors are closed and
other things registered with the closer are not.  Changing the code to hack
a custom guice module to extract out the closer and do this is possible,
but  I can promise no-one would want to maintain the mock code or
understand it.  So, I understand the risk, and hope you can live with the
gap.


On Mon, Apr 8, 2013 at 3:14 PM, Andrew Phillips <notifications@github.com>wrote:

> In
> core/src/test/java/org/jclouds/rest/annotationparsing/ClosableApiTest.java:
>
> > +         "http://mock");
> > +
> > +   public void testApiClosesExecutorServiceOnClose() throws IOException {
> > +      ListeningExecutorService executor = createMock(ListeningExecutorService.class);
> > +
> > +      expect(executor.shutdownNow()).andReturn(ImmutableList.<Runnable> of()).atLeastOnce();
> > +
> > +      replay(executor);
> > +
> > +      DelegatingApi api = ContextBuilder.newBuilder(provider)
> > +                                        .modules(ImmutableSet.<Module> builder()
> > +                                                             .add(new ExecutorServiceModule(executor, executor))
> > +                                                             .build())
> > +                                        .buildApi(DelegatingApi.class);
> > +      api.close();
> > +      verify(executor);
>
>  The intent is to close the executorservice
>
> Aha, thanks for the explanation. Is the Closer supposed to close anything
> else? Not with that module set, I guess..?
>
> My point is: is the *intent* to invoke the Closer (with the assumption
> that that's the contract for any "proper" closing) or is Closer just
> regarded as an implementation detail?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/jclouds/jclouds/pull/1503/files#r3704285>
> .
>