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 <kdul...@pivotal.io> 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 temporarily mark those tests with @Ignore, a basic 'gradle build' > succeeds. I'm waiting on the results for a precheckin. > > > > > > On Tue, Aug 16, 2016 at 1:11 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > 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-security.version = 3.1.7.RELEASE ----> 4.1.2 > spring-tx.version > > = 3.2.12.RELEASE ----> 4.3.2 springframework.version = 4.2.4.RELEASE > ----> > > 4.3.2 > > > > > > > > On 17/08/2016 2:03 AM, Kevin Duling wrote: > > > >> 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 16, 2016 at 8:53 AM, Anthony Baker <aba...@pivotal.io> > wrote: > >> > >> 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 > >>> sort out the full list of version changes needed. > >>> > >>> Anthony > >>> > >>> On Aug 16, 2016, at 8:39 AM, Kevin Duling <kdul...@pivotal.io> wrote: > >>>> > >>>> 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 <main> tid=0x1] loader constraint > >>>> violation: when resolving method "org.slf4j.impl.StaticLoggerBinder. > >>>> getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader > >>>> > >>> (instance of > >>> > >>>> org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, > >>>> org/slf4j/LoggerFactory, and the class loader (instance of > >>>> sun/misc/Launcher$AppClassLoader) for the method's defining class, > >>>> org/slf4j/impl/StaticLoggerBinder, have different Class objects for > the > >>>> type org/slf4j/ILoggerFactory used in the signature > >>>> java.lang.LinkageError: loader constraint violation: when resolving > >>>> > >>> method > >>> > >>>> "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ > >>>> > >>> ILoggerFactory;" > >>> > >>>> the class loader (instance of org/eclipse/jetty/webapp/ > >>>> > >>> WebAppClassLoader) > >>> > >>>> of the current class, org/slf4j/LoggerFactory, and the class loader > >>>> (instance of sun/misc/Launcher$AppClassLoader) for the method's > >>>> defining > >>>> class, org/slf4j/impl/StaticLoggerBinder, have different Class > objects > >>>> > >>> for > >>> > >>>> the type org/slf4j/ILoggerFactory used in the signature > >>>> > >>> > >>> > > >
