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