[Discuss] Member Launcher API

[Patrick Rhomberg <pr...@pivotal.io>]

Hello, all.

  There has been some discussion [1] on the JIRA regarding GEODE-3584, to
reduce code duplication and improve clarity across LocatorLauncher,
ServerLauncher, and AbstractLauncher classes.
  In no particular order, I think the following would be a good starting
point for refactoring these classes:

* To reduce duplication:
*** Unify ServerLauncher.Command and LocatorLauncher.Command enums to a
single enum.
*** Unify ServerLauncher.ServerState and LocatorLauncher.LocatorState to a
single "MemberState" class.
*** Unify redundancy in ServerLauncher.ServerControllerParams and
LocatorLauncher.LocatorControllerParams to an shared base class.

* To improve clarity in classes that are currently large:
*** Promote inner classes ServerLauncher.Builder and
LocatorLauncher.Builder to be "top-level" classes.
*** Promote inner classes ServerLauncher.State and LocatorLauncher.State to
be "top-level" classes.
*** Possibly promote inner classes ServerLauncher.ServerControllerParams
and LocatorLauncher.LocatorControllerParams, although the footprint of each
would be very small after the above refactor.  Alternatively, make the
inner class implementations

Each of these refactors would require deprecation of existing public-facing
points and delegation at those points to the new classes.

The above are initial impressions.  I haven't spent much time digging into
the viability of each refactor, but it does appear that the inner classes
do not heavily rely on visibility of class fields that would be otherwise
inaccessible.

Thoughts or concerns on these API relocations?

Imagination is Change.
~Patrick Rhomberg

[1] https://issues.apache.org/jira/browse/GEODE-3584

Re: [Discuss] Member Launcher API

[Kirk Lund <kl...@apache.org>]

You might want to also consider moving these Launcher classes from
org.apache.geode.distributed to some other package such as one of the
following:

1) org.apache.geode
2) org.apache.geode.api
3) org.apache.geode.launcher
4) org.apache.geode.management
5) org.apache.geode.process

The existing Launcher classes would be deprecated and you could rewrite all
Geode code to use new Launchers in the new package.

On Mon, Feb 26, 2018 at 11:42 AM, Patrick Rhomberg <pr...@pivotal.io>
wrote:

> Hello, all.
>
>   There has been some discussion [1] on the JIRA regarding GEODE-3584, to
> reduce code duplication and improve clarity across LocatorLauncher,
> ServerLauncher, and AbstractLauncher classes.
>   In no particular order, I think the following would be a good starting
> point for refactoring these classes:
>
> * To reduce duplication:
> *** Unify ServerLauncher.Command and LocatorLauncher.Command enums to a
> single enum.
> *** Unify ServerLauncher.ServerState and LocatorLauncher.LocatorState to a
> single "MemberState" class.
> *** Unify redundancy in ServerLauncher.ServerControllerParams and
> LocatorLauncher.LocatorControllerParams to an shared base class.
>
> * To improve clarity in classes that are currently large:
> *** Promote inner classes ServerLauncher.Builder and
> LocatorLauncher.Builder to be "top-level" classes.
> *** Promote inner classes ServerLauncher.State and LocatorLauncher.State to
> be "top-level" classes.
> *** Possibly promote inner classes ServerLauncher.ServerControllerParams
> and LocatorLauncher.LocatorControllerParams, although the footprint of
> each
> would be very small after the above refactor.  Alternatively, make the
> inner class implementations
>
> Each of these refactors would require deprecation of existing public-facing
> points and delegation at those points to the new classes.
>
> The above are initial impressions.  I haven't spent much time digging into
> the viability of each refactor, but it does appear that the inner classes
> do not heavily rely on visibility of class fields that would be otherwise
> inaccessible.
>
> Thoughts or concerns on these API relocations?
>
> Imagination is Change.
> ~Patrick Rhomberg
>
> [1] https://issues.apache.org/jira/browse/GEODE-3584
>