Extract a thread-safe implementation of Lister from AdaptorLister

Extract a thread-safe implementation of Lister from AdaptorLister.

The Connector Manager has a race condition when calling start and
shutdown. This was fixed in AdaptorLister (then GroupLister) in commit
3d825b0. The intent is for the new AbstractLister abstract class to be
moved to Connector Manager as an improvement over the bare Lister
interface.

I gave up trying to get git diff -C -C to recognize the copies of the
extracted files. Instead, I am using multiple patch sets.

Patch set 1:

AbstractLister.java: an unedited copy of AdaptorLister.java
AbstractListerTest.java: a copy of the edited AdaptorListerTest.java
AdaptorListerTest.java: edited to cleanup leftovers from commit 9f052d6

Patch set 2:

AbstractLister.java: extracted the thread-safe start and shutdown methods
AdaptorLister.java: reduced to just the new init, run, and destroy methods
AbstractListerTest.java: edited to avoid using an Adaptor for testing
AdaptorListerTest.java: no changes

[JohnL, 2015-05-03 04:36:53]

Extract AbstractLister

[Brett, 2015-05-05 02:06:28]

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
File
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java
(right):

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:40:
* {@code run} exits then {@code destroy} will not be called. Like the
This contradicts the javadoc for destroy() itself.  If destroy is meant to clean
up resources allocated in init(), then it should always be called if init
returned, no matter how run() behaved.

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:86:
* Cleans up any resources allocated by {@link #init} or {@link #destroy}.
destroy() or run()?

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:110:
run();
Call destroy() here, and keep a flag indicating whether destroy has been called.

[JohnL, 2015-05-05 05:26:29]

Addressing Brett's comments.

John L

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
File
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java
(right):

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:40:
* {@code run} exits then {@code destroy} will not be called. Like the
On 2015/05/05 02:06:28, Brett wrote:
> This contradicts the javadoc for destroy() itself.  If destroy is meant to
clean
> up resources allocated in init(), then it should always be called if init
> returned, no matter how run() behaved.

s/will/may/ to match destroy, and added a TODO to always call destroy.

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:86:
* Cleans up any resources allocated by {@link #init} or {@link #destroy}.
On 2015/05/05 02:06:28, Brett wrote:
> destroy() or run()?

s/destroy/run/

https://codereview.appspot.com/235910043/diff/20001/projects/otex-core/source...
projects/otex-core/source/java/com/google/enterprise/connector/otex/AbstractLister.java:110:
run();
On 2015/05/05 02:06:28, Brett wrote:
> Call destroy() here, and keep a flag indicating whether destroy has been
called.

Acknowledged.

[JohnL, 2015-05-05 05:27:56]

Code review comments

[Brett, 2015-05-05 17:17:24]

LGTM

[Srinivas, 2015-05-27 03:55:12]

On 2015/05/05 17:17:24, Brett wrote:
> LGTM

LGTM

[JohnL, 2015-05-29 06:38:06]

Committed:
https://github.com/googlegsa/livelink.v3/commit/3bc7c18a2d13d4fa5615ebd20c630...

John L