Re: Release branch for Apache Geode 1.8.0 has been cut

[Nabarun Nag]

I would also like to put in the fix for GEODE-6053. It's in the review phase 
and soon will be in the develop and the release branch.

Regards
Nabarun Nag

> On Nov 14, 2018, at 10:28 AM, Jason Huynh  wrote:
> 
> I'd like to cherry pick the following two commits to release/1.8.
> 
> 
> https://github.com/apache/geode/commit/6d9e026feb584309dff269e593417082a71434fc
> 
> https://github.com/apache/geode/commit/d22e83e167f261e933b79b2619367d2e1b788db6
> 
> 
> Reason: There was a previous commit that modified the way
> FunctionInvocationTargetExceptions were being wrapped or sent back to the
> client.  This could negatively impact a user that was drilling down into
> exceptions.getCause() methods as sometimes it would be null.  These two
> commits restore the behavior for any client between 1.0-1.7.
> 
> 
> Thanks,
> 
> -Jason
> 
> On Mon, Nov 12, 2018 at 5:47 PM Ryan McMahon  wrote:
> 
>> Hi Alexander,
>> 
>> I would like to cherry pick the following commits from develop to
>> release/1.8.0:
>> 
>> 
>> https://github.com/apache/geode/commit/e9ea18e18c85b977b91192d4edbb9a4e18b2643e
>> *Reason*: This was a revert of a previous commit which addressed data
>> inconsistencies between WAN sites, but it was found the fix introduced
>> several other inconsistencies.
>> 
>> 
>> https://github.com/apache/geode/commit/aab0198e8478d4246042b2eb889c8ce7e28bb52e
>> *Reason: *This fixes a race condition in the QueryMonitor which causes an
>> unexpected RejectedExecutionException in monitorQuery()
>> 
>> Please let me know if this sounds reasonable and I can go ahead and begin
>> the cherry picking process.
>> 
>> Thanks!
>> Ryan
>> 
>> 
>> On Thu, Nov 8, 2018 at 1:54 PM Alexander Murmann 
>> wrote:
>> 
>>> Hello everyone,
>>> 
>>> As discussed previously created a new release branch for Apache Geode
>> 1.8.0
>>> - "release/1.8.0"
>>> 
>>> Please do review and raise any concern with the release branch.
>>> If no concerns are raised, we will start with the voting for the release
>>> candidate soon.
>>> 
>>> This also means that all tickets JIRA that get resolved on develop should
>>> be marked with 1.9.0 as their fix version.
>>> 
>>> Thanks!
>>> 
>>> Alexander
>>> 
>> 

Re: PowerMock unit test errors

[Bruce Schuchardt]

I don't think you necessarily need to redo your work Ryan.  I just think 
something has been left behind by the test.  It looks like a mock made 
its way into  the JMX "Server" in the log4j code.


On 11/14/18 10:57 AM, Ryan McMahon wrote:

I will write up a story to address the use of PowerMock in these JMX tests
in particular.  I remember attempting to avoid PowerMock when writing this
test, because I agree that it should be avoided.  I just want to explain my
thinking so that we can discuss what would have been a better approach.

In this particular set of tests, I used it to mock two static methods:
1. InternalDistributedSystem.getConnectedInstance()
2. LogService.getLogger()

I considered making these instance methods as part of this ticket.  When I
started down that path, I found there are 41 calls to
InternalDistributedSystem.getConnectedInstance(), and many of the callers
have no reference to an instance of InternalDistributedSystem.  While I
think this is a solvable problem, it would have vastly increased the scope
of the work involved.  Would this ticket have been the place to do that
work?  I am under the impression that we have some Jira tickets
specifically related to removing statics.  Are those more aptly fit for
that work?

I agree that the LogService could have been injected in the MBeanJMXAdapter
constructor, so that would have been a reasonable API change to make this
testable without mocking the static LogService.  However, I'm still
interested in what people think about the InternalDistributedSystem case
described above.

There are ways I could have changed the public API of
InternalDistributedSystem and related classes to make them testable without
the use of PowerMock.  There are a lot of ways to do this, but they all
boil down to adding test hooks in public API.  Is that better than using
PowerMock?  I see the following options:

1. Don't test at this level which requires mocking statics
2. Use PowerMock
3. Add test hooks (perhaps make InternalDistributedSystem wrap a singleton
which you can swap for a test object, but there are other ways to do this)
4. Do major refactoring to eliminate the statics involved

I don't think that not testing at this level is a great solution.  We've
discussed the disadvantages of PowerMock already, so the cons of #2 are
well known.  I am not a fan of adding public API test hooks, and in this
case I'd rather use PowerMock honestly, but that is highly subjective.  And
#4 is the "ideal world" case, but isn't always practically possible given
the scope of the work involved.

I'm curious what other people think about this topic?

Thanks,
Ryan






On Tue, Nov 6, 2018 at 10:40 AM Kirk Lund  wrote:


I think we should try really hard to avoid using PowerMock. If you have
some code that you need to use PowerMock to make it testable, please
consider refactoring the code to a) avoid statics, b) pass all dependencies
in via the constructor.

The following was spit out by one of my unit test runs. None of the logging
or log4j tests in my PR involve PowerMock. Also, this unit test run had no
FAILED tests, so this would appear to be generated by some unit test that
uses PowerMock and PASSED.


Task :geode-core:test

2018-11-06 18:03:49,443 Distributed system shutdown hook ERROR Could not
reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
(instance of org/powermock/core/classloader/MockClassLoader) previously
initiated loading for a different type with name
"javax/management/MBeanServer"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at

org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
at

org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
at

org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
at

org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at

org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
at

org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:259)
at

org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:164)
at

org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:140)
at

org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
at

org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
at

org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
at

org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
at

org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at 

Re: PowerMock unit test errors

[Ryan McMahon]

I've created a Jira to track the elimination of PowerMock from these tests
in particular, which will probably involve doing the major refactoring
mentioned in item #4 in my previous email.

https://issues.apache.org/jira/browse/GEODE-6052

On Wed, Nov 14, 2018 at 10:57 AM Ryan McMahon 
wrote:

> I will write up a story to address the use of PowerMock in these JMX tests
> in particular.  I remember attempting to avoid PowerMock when writing this
> test, because I agree that it should be avoided.  I just want to explain my
> thinking so that we can discuss what would have been a better approach.
>
> In this particular set of tests, I used it to mock two static methods:
> 1. InternalDistributedSystem.getConnectedInstance()
> 2. LogService.getLogger()
>
> I considered making these instance methods as part of this ticket.  When I
> started down that path, I found there are 41 calls to
> InternalDistributedSystem.getConnectedInstance(), and many of the callers
> have no reference to an instance of InternalDistributedSystem.  While I
> think this is a solvable problem, it would have vastly increased the scope
> of the work involved.  Would this ticket have been the place to do that
> work?  I am under the impression that we have some Jira tickets
> specifically related to removing statics.  Are those more aptly fit for
> that work?
>
> I agree that the LogService could have been injected in the
> MBeanJMXAdapter constructor, so that would have been a reasonable API
> change to make this testable without mocking the static LogService.
> However, I'm still interested in what people think about the
> InternalDistributedSystem case described above.
>
> There are ways I could have changed the public API of
> InternalDistributedSystem and related classes to make them testable without
> the use of PowerMock.  There are a lot of ways to do this, but they all
> boil down to adding test hooks in public API.  Is that better than using
> PowerMock?  I see the following options:
>
> 1. Don't test at this level which requires mocking statics
> 2. Use PowerMock
> 3. Add test hooks (perhaps make InternalDistributedSystem wrap a singleton
> which you can swap for a test object, but there are other ways to do this)
> 4. Do major refactoring to eliminate the statics involved
>
> I don't think that not testing at this level is a great solution.  We've
> discussed the disadvantages of PowerMock already, so the cons of #2 are
> well known.  I am not a fan of adding public API test hooks, and in this
> case I'd rather use PowerMock honestly, but that is highly subjective.  And
> #4 is the "ideal world" case, but isn't always practically possible given
> the scope of the work involved.
>
> I'm curious what other people think about this topic?
>
> Thanks,
> Ryan
>
>
>
>
>
>
> On Tue, Nov 6, 2018 at 10:40 AM Kirk Lund  wrote:
>
>> I think we should try really hard to avoid using PowerMock. If you have
>> some code that you need to use PowerMock to make it testable, please
>> consider refactoring the code to a) avoid statics, b) pass all
>> dependencies
>> in via the constructor.
>>
>> The following was spit out by one of my unit test runs. None of the
>> logging
>> or log4j tests in my PR involve PowerMock. Also, this unit test run had no
>> FAILED tests, so this would appear to be generated by some unit test that
>> uses PowerMock and PASSED.
>>
>> > Task :geode-core:test
>> 2018-11-06 18:03:49,443 Distributed system shutdown hook ERROR Could not
>> reconfigure JMX java.lang.LinkageError: loader constraint violation:
>> loader
>> (instance of org/powermock/core/classloader/MockClassLoader) previously
>> initiated loading for a different type with name
>> "javax/management/MBeanServer"
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>> at
>>
>> org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
>> at
>>
>> org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
>> at
>>
>> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
>> at
>>
>> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at
>>
>> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
>> at
>>
>> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:259)
>> at
>>
>> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:164)
>> at
>>
>> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:140)
>> at
>>
>> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
>> at
>>
>> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
>> at
>>
>> 

Re: PowerMock unit test errors

[Ryan McMahon]

I will write up a story to address the use of PowerMock in these JMX tests
in particular.  I remember attempting to avoid PowerMock when writing this
test, because I agree that it should be avoided.  I just want to explain my
thinking so that we can discuss what would have been a better approach.

In this particular set of tests, I used it to mock two static methods:
1. InternalDistributedSystem.getConnectedInstance()
2. LogService.getLogger()

I considered making these instance methods as part of this ticket.  When I
started down that path, I found there are 41 calls to
InternalDistributedSystem.getConnectedInstance(), and many of the callers
have no reference to an instance of InternalDistributedSystem.  While I
think this is a solvable problem, it would have vastly increased the scope
of the work involved.  Would this ticket have been the place to do that
work?  I am under the impression that we have some Jira tickets
specifically related to removing statics.  Are those more aptly fit for
that work?

I agree that the LogService could have been injected in the MBeanJMXAdapter
constructor, so that would have been a reasonable API change to make this
testable without mocking the static LogService.  However, I'm still
interested in what people think about the InternalDistributedSystem case
described above.

There are ways I could have changed the public API of
InternalDistributedSystem and related classes to make them testable without
the use of PowerMock.  There are a lot of ways to do this, but they all
boil down to adding test hooks in public API.  Is that better than using
PowerMock?  I see the following options:

1. Don't test at this level which requires mocking statics
2. Use PowerMock
3. Add test hooks (perhaps make InternalDistributedSystem wrap a singleton
which you can swap for a test object, but there are other ways to do this)
4. Do major refactoring to eliminate the statics involved

I don't think that not testing at this level is a great solution.  We've
discussed the disadvantages of PowerMock already, so the cons of #2 are
well known.  I am not a fan of adding public API test hooks, and in this
case I'd rather use PowerMock honestly, but that is highly subjective.  And
#4 is the "ideal world" case, but isn't always practically possible given
the scope of the work involved.

I'm curious what other people think about this topic?

Thanks,
Ryan






On Tue, Nov 6, 2018 at 10:40 AM Kirk Lund  wrote:

> I think we should try really hard to avoid using PowerMock. If you have
> some code that you need to use PowerMock to make it testable, please
> consider refactoring the code to a) avoid statics, b) pass all dependencies
> in via the constructor.
>
> The following was spit out by one of my unit test runs. None of the logging
> or log4j tests in my PR involve PowerMock. Also, this unit test run had no
> FAILED tests, so this would appear to be generated by some unit test that
> uses PowerMock and PASSED.
>
> > Task :geode-core:test
> 2018-11-06 18:03:49,443 Distributed system shutdown hook ERROR Could not
> reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
> (instance of org/powermock/core/classloader/MockClassLoader) previously
> initiated loading for a different type with name
> "javax/management/MBeanServer"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
>
> org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
> at
>
> org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
> at
>
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
> at
>
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
>
> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
> at
>
> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:259)
> at
>
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:164)
> at
>
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:140)
> at
>
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
> at
>
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
> at
>
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
> at
>
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
> at
>
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:661)
> 

Re: Release branch for Apache Geode 1.8.0 has been cut

[Jason Huynh]

I'd like to cherry pick the following two commits to release/1.8.


https://github.com/apache/geode/commit/6d9e026feb584309dff269e593417082a71434fc

https://github.com/apache/geode/commit/d22e83e167f261e933b79b2619367d2e1b788db6


Reason: There was a previous commit that modified the way
FunctionInvocationTargetExceptions were being wrapped or sent back to the
client.  This could negatively impact a user that was drilling down into
exceptions.getCause() methods as sometimes it would be null.  These two
commits restore the behavior for any client between 1.0-1.7.


Thanks,

-Jason

On Mon, Nov 12, 2018 at 5:47 PM Ryan McMahon  wrote:

> Hi Alexander,
>
> I would like to cherry pick the following commits from develop to
> release/1.8.0:
>
>
> https://github.com/apache/geode/commit/e9ea18e18c85b977b91192d4edbb9a4e18b2643e
> *Reason*: This was a revert of a previous commit which addressed data
> inconsistencies between WAN sites, but it was found the fix introduced
> several other inconsistencies.
>
>
> https://github.com/apache/geode/commit/aab0198e8478d4246042b2eb889c8ce7e28bb52e
> *Reason: *This fixes a race condition in the QueryMonitor which causes an
> unexpected RejectedExecutionException in monitorQuery()
>
> Please let me know if this sounds reasonable and I can go ahead and begin
> the cherry picking process.
>
> Thanks!
> Ryan
>
>
> On Thu, Nov 8, 2018 at 1:54 PM Alexander Murmann 
> wrote:
>
> > Hello everyone,
> >
> > As discussed previously created a new release branch for Apache Geode
> 1.8.0
> > - "release/1.8.0"
> >
> > Please do review and raise any concern with the release branch.
> > If no concerns are raised, we will start with the voting for the release
> > candidate soon.
> >
> > This also means that all tickets JIRA that get resolved on develop should
> > be marked with 1.9.0 as their fix version.
> >
> > Thanks!
> >
> > Alexander
> >
>

November 2018 Board Report Final Draft

[Robert Houghton]

Here is the final form our report for the quarter. If it passes muster, can
someone commit it to the Apache repository for me?

## Description:
>
> Apache Geode provides a database-like consistency model, reliable
>> transaction
>
> processing and a shared-nothing architecture to maintain very low latency
>
> performance with high concurrency processing.
>
>
>> ## Issues:
>
> There are no issues requiring board attention at this time.
>
>
>> ## Activity:
>
> - We released v1.7.0, containing 859 commits resolving 196 bugs, 98
>> improvements
>
>  and features, and a total of 357 JIRA tickets
>
> - We've made a number of build improvements, including upgrading to Gradle
>> v4.10.1
>
> - We've begun testing with Java 11 and have added automated Windows
>> testing to our CI jobs.
>
> - We have reviewed and acted on a number of code issues reported by
>> lgtm.com .
>
> - We discussed use of Lombok and decided that adoption would prove to be a
>> barrier to users and contributors.
>
> - We added a notifications@ mailing list to track GitHub PR activity.
>
> - We agreed to adopt a quarterly release schedule to improve
>> predictability of releases.
>
> - We reorganized the top-level wiki for better navigation and
>> discoverability.  We also added a page to track conference
>
>  presentations, blog postings, and other media.
>
> - The Geode Summit at SpringOnePlatform 2018 was very well-attended with
>> over 400 people filling the conference room.
>
>  Both users and committers alike presented 15 talks during the
>> conference.  The sessions were recorded and available on
>
>  youtube.
>
>
>>
>> ## Health report:
>
> - Overall project momentum is picking back up. We are seeing good results
>> from the efforts
>
>  to improve test reliability
>
>
>> ## PMC changes:
>
>
>> - Currently 46 PMC members.
>
> - No new PMC members added in the last 3 months
>
> - Last PMC addition was Dick Cavender on Tue Feb 20 2018
>
>
>
> ## Committer base changes:
>
>
>> - Currently 98 committers.
>
> - New commmitters:
>
>- Addison Huddy was added as a committer on Sat Sep 01 2018
>
>- Alexander Murmann was added as a committer on Sat Sep 08 2018
>
>- Blake Bender was added as a committer on Sat Sep 01 2018
>
>- Helena Bales was added as a committer on Sat Sep 01 2018
>
>- Ivan Godwin was added as a committer on Sat Sep 01 2018
>
>- Juan Ramos was added as a committer on Sat Sep 08 2018
>
>- Ryan McMahon was added as a committer on Sat Sep 01 2018
>
>- Michael Martell was added as a committer on Sat Sep 08 2018
>
>- Michael Oleske was added as a committer on Sat Sep 08 2018
>
>- Robert Houghton was added as a committer on Mon Oct 01 2018
>
>- Sean Goller was added as a committer on Sat Sep 01 2018
>
>
>> ## Releases:
>
>
>> - 1.7.0 was released on Thu Oct 04 2018
>
> - We have begun work on the 1.8.0 release.  We expect the release to
>> include geode-native (a C++/C# client for Geode)
>
>  for the first time.
>
> - We're continuing to rotate release manager duties among committers to
>> ensure the release process is well documented
>
>  and repeatable.
>
>
>> ## Mailing list activity:
>
>
>> - Mailing lists have remained active and have been seen a marked increase
>> in use
>
>  for both development and issues
>
> - The increase in the user@ mailing list is very encouraging and seems to
>> correlate with the Geode Summit.
>
>
>> - dev@geode.apache.org:
>
>- 190 subscribers (up 8 in the last 3 months):
>
>- 889 emails sent to list (624 in previous quarter)
>
>
>
> - iss...@geode.apache.org:
>
>- 55 subscribers (up 1 in the last 3 months):
>
>- 4283 emails sent to list (2707 in previous quarter)
>
>
>
> - notificati...@geode.apache.org:
>
>- 7 subscribers (up 7 in the last 3 months):
>
>- 1998 emails sent to list (0 in previous quarter)
>
>
>
> - u...@geode.apache.org:
>
>- 249 subscribers (up 7 in the last 3 months):
>
>- 201 emails sent to list (138 in previous quarter)
>
>
>
>
>
> ## JIRA activity:
>
>
>> - 456 JIRA tickets created in the last 3 months
>
> - 485 JIRA tickets closed/resolved in the last 3 months
>
>
>>

Re: PowerMock unit test errors

[Bruce Schuchardt]

I'm running into the same PowerMock problem that Kirk hit.  I can find 
only one test that uses PowerMock and invokes registerMBean - 
MBeanJMXAdapterTest.  This is a new test that was checked in mid-October.


commit 76420dcd93e17f009aa73ca8188d135158358323
Author: Ryan McMahon 
Date:   Wed Oct 17 10:21:03 2018 -0700

    GEODE-5857: Handle JMX race conditions during registration and cleanup


Maybe it needs to do more cleanup


On 11/6/18 10:40 AM, Kirk Lund wrote:


I think we should try really hard to avoid using PowerMock. If you have
some code that you need to use PowerMock to make it testable, please
consider refactoring the code to a) avoid statics, b) pass all dependencies
in via the constructor.

The following was spit out by one of my unit test runs. None of the logging
or log4j tests in my PR involve PowerMock. Also, this unit test run had no
FAILED tests, so this would appear to be generated by some unit test that
uses PowerMock and PASSED.


Task :geode-core:test

2018-11-06 18:03:49,443 Distributed system shutdown hook ERROR Could not
reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
(instance of org/powermock/core/classloader/MockClassLoader) previously
initiated loading for a different type with name
"javax/management/MBeanServer"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
at
org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
at
org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
at
org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
at
org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:259)
at
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:164)
at
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:140)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:661)
at
org.apache.geode.internal.logging.LogService.getLogger(LogService.java:64)
at
org.apache.geode.internal.tcp.ConnectionTable.(ConnectionTable.java:61)
at
org.apache.geode.distributed.DistributedSystem.setThreadsSocketPolicy(DistributedSystem.java:263)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$0(InternalDistributedSystem.java:2320)
at java.lang.Thread.run(Thread.java:748)