You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by "Ju@N" <ju...@gmail.com> on 2018/10/15 14:14:41 UTC

Help With ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest

Hello all,

Working through GEODE-5739
<https://issues.apache.org/jira/browse/GEODE-5739> I've modified
*ServerStarterRule* and *LocatorStarterRule* to use the public
*ServerLauncher* and *LocatorLauncher* classes respectively, instead of the
internal APIs to start up the members. As part of the changes, I've
modified the accessibility of some methods to be *public* instead of
*private/protected* (like *getLogFile* so member's logs are redirected to
console) and made use of some methods not present at all in older versions
(like *setDeletePidFileOnStop*). This causes the test of the subject to fail
<http://files.apachegeode-ci.info/builds/geode-pr-2604/test-results/distributedTest/1539612211/>
when trying to invoke those if the user requested  using older versions of
Geode (*IllegalAccessError*, *NoSuchMethodError*, etc.)...
Considering that these changes don't actually break the backward
compatibility for the product itself, what would be the best solution here?:

   - Discard the changes and leave the rules as they currently are (rules
   will continue to use internal APIs instead of launchers).
   - Extend the current rules, deprecate the old ones, and tweak the
   *ClusterStartupRule* to choose the correct rule instance when starting
   members based on the requested version.
   - Modify the rules to use the old approach (internal APIs) whenever they
   detect that the user has requested to start a member using an older version
   of the product.
   - Other?.

Best regards.

-- 
Ju@N

Re: Help With ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest

Posted by "Ju@N" <ju...@gmail.com>.
Hello all,

Looks like the JIRA must not be fixed (see this thread [1]) and that the
rules should not be modified to use LocatorLauncher/ServerLauncher instead
of the internal API, so I'll close both the pull request [1] and GEODE-5739
[2].
Jason: you opened the original JIRA a couple of weeks ago, let me know if
you still think it should be fixed and I'll create a DISCUSS thread to move
forward.
Best regards.

[1]: https://github.com/apache/geode/pull/2604
[2]: https://issues.apache.org/jira/browse/GEODE-5739


On Mon, Oct 15, 2018 at 3:14 PM Ju@N <ju...@gmail.com> wrote:

> Hello all,
>
> Working through GEODE-5739
> <https://issues.apache.org/jira/browse/GEODE-5739> I've modified
> *ServerStarterRule* and *LocatorStarterRule* to use the public
> *ServerLauncher* and *LocatorLauncher* classes respectively, instead of
> the internal APIs to start up the members. As part of the changes, I've
> modified the accessibility of some methods to be *public* instead of
> *private/protected* (like *getLogFile* so member's logs are redirected to
> console) and made use of some methods not present at all in older versions
> (like *setDeletePidFileOnStop*). This causes the test of the subject to
> fail
> <http://files.apachegeode-ci.info/builds/geode-pr-2604/test-results/distributedTest/1539612211/>
> when trying to invoke those if the user requested  using older versions of
> Geode (*IllegalAccessError*, *NoSuchMethodError*, etc.)...
> Considering that these changes don't actually break the backward
> compatibility for the product itself, what would be the best solution here?:
>
>    - Discard the changes and leave the rules as they currently are (rules
>    will continue to use internal APIs instead of launchers).
>    - Extend the current rules, deprecate the old ones, and tweak the
>    *ClusterStartupRule* to choose the correct rule instance when starting
>    members based on the requested version.
>    - Modify the rules to use the old approach (internal APIs) whenever
>    they detect that the user has requested to start a member using an older
>    version of the product.
>    - Other?.
>
> Best regards.
>
> --
> Ju@N
>


-- 
Ju@N