We should probably make changes to GfshInitFileJunitTest to remove all of
the reflection-based logger manipulation. We could use PowerMock and/or
SystemOutRule/SystemErrRule and probably greatly reduce the size and
fragility of this test.
-Kirk
On Tue, Aug 16, 2016 at 3:11 PM, Kevin Duling wrote
So I tried that, and GfshInitFileJunitTest has three tests that fail
because a CommandProcessingException is now being thrown where it wasn't
before.
Specifically, the tests are:
- testInitFile_TwoBadCommands
- testInitFile_OneBadCommand
- testInitFile_BadAndGoodCommands
If I temporaril
I think, if were going to upgrade to 4.1.2, we might considering
upgrading the rest of the Spring libraries to the 4.3.2 compatible.
spring-hateos.version = 0.16.0.RELEASE > 0.21.0 spring-shell.version
= 1.1.0.RELEASE > 1.2.0 spring-ldap-core.version = 1.3.2.RELEASE
> 2.1.0 spring-
Yes, that's my experience so far. But this particular error persists
regardless of how deep down the rabbit hole I gone and I haven't been able
to solve it. I think it's due to an older slf4j being bundled in to jetty.
I'll give those commands a try and see whether they help or not.
On Tue, Aug
Not sure if this is related to your error, but it looks like that version of
spring-security would at least require moving to spring framework 4.3.1 and
possibly more dep updates as well. You should be able to run some gradle
commands (dependencies, dependencyInsight, dumpDependencies) to help
I'm working on adding security to the REST methods and wanted to start by
upgrading spring-security to the latest version.
Bumping the version from 4.1.1 from 3.1.7, I ran in to
GfshCommandsOverHttpSecurityTest failing under geode-web. The error was:
[warn 2016/08/12 15:37:52.078 PDT tid=0x1] l
