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

Cyrille Artho updated GEODE-3584:
---------------------------------
    Attachment: GEODE-3584-1

A first step is done!

Patch GEODE-3584-1 covers the refactoring of the inner "Builder" class. As much 
code as possible is now shared in super class AbstractLauncher, which now has 
its own abstract Builder class that contains all the shared code.

This patch also makes some field/method names consistent across both classes: 
"serverPort", "serverBindAddress", etc., have been shortened to "port", 
"bindAddress", etc., to be consistent with LocatorLauncher. All unit tests are 
updated accordingly. The command line syntax has *not* been changed.

The camel case spelling of "hostname" is now fixed to "hostName" (in 
LocatorLauncher), to be consistent with ServerLauncher and the Java base 
libraries.

All unit tests pass.

*Remaining issues:*
* A few Javadoc references are now outdated, and more refactoring has to be 
done in the two classes themselves (and perhaps other inner/static classes).
* Refactoring of the "Command" enumeration can be done as soon as GEODE-4183 is 
resolved.
* More refactoring opportunities will arise in the Builder classes once the 
main code has been refactored.

> Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
> -------------------------------------------------------------------------
>
>                 Key: GEODE-3584
>                 URL: https://issues.apache.org/jira/browse/GEODE-3584
>             Project: Geode
>          Issue Type: Improvement
>          Components: gfsh
>    Affects Versions: 1.2.0
>            Reporter: Kenneth Howe
>         Attachments: GEODE-3584-1, GEODE-3584-WIP, GEODE-3584-WIP-2, 
> GEODE-3584-WIP-3, GEODE-3584-WIP-4
>
>
> There is some duplication of code in the Launcher classes that can be 
> eliminated. Both classes have methods such as getBindAddress (called 
> getServerBindAddress in ServerLauncher) that could be hoisted into  
> AbstractLauncher class that they both extend. The same goes for the inner 
> State classes of the Launchers; they have methods that could be moved to 
> AbstractLauncher.ServiceState.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to