[JBoss JIRA] (WFLY-1804) Ensure Subject of remote user is associated with the AccessControContext handling the request.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1804?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved REMJMX-61 to WFLY-1804:
----------------------------------------------
Project: WildFly (was: Remoting JMX)
Key: WFLY-1804 (was: REMJMX-61)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: JMX
Remoting
Security
(was: Security)
Fix Version/s: 8.0.0.Alpha4
(was: 1.1.1.CR1)
(was: 2.0.0.Beta2)
> Ensure Subject of remote user is associated with the AccessControContext handling the request.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-1804
> URL: https://issues.jboss.org/browse/WFLY-1804
> Project: WildFly
> Issue Type: Task
> Components: JMX, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha4
>
>
> WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
> As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
> No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
> This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-205?page=com.atlassian.jira.plugi... ]
Scott Marlow updated JASSIST-205:
---------------------------------
Attachment: PowerMockTest.javap
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-205
> URL: https://issues.jboss.org/browse/JASSIST-205
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: jdk1.7.0_21, Win8amd64
> Reporter: Ryan Kenney
> Assignee: Shigeru Chiba
> Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt, PowerMockTest.javap
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> /**************************************************************************
> * Demonstrates an "Inconsistent stackmap frames" exception that results
> * from PowerMock 1.5 and JDK 7.
> *************************************************************************/
> @Test
> public void testWaitForExitMockMonitors() throws InterruptedException {
> resetAll();
>
> Object mockMonitor = createStrictMock(Object.class);
> MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
>
> mockMonitor.wait(0);
> mockMonitor.notifyAll();
>
> replayAll();
>
> myClass .run();
>
> verifyAll();
> }
>
> public static class MyClassUnderTest {
> private Object m_monitor;
>
> public MyClassUnderTest(Object monitor) {
> m_monitor = monitor;
> }
>
> public void run() throws InterruptedException {
> m_monitor.wait(0);
> m_monitor.notifyAll();
> }
> }
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> at java.lang.Class.getMethods(Class.java:1429)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-205?page=com.atlassian.jira.plugi... ]
Scott Marlow updated JASSIST-205:
---------------------------------
Attachment: powermockdemoDEBUG.txt
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-205
> URL: https://issues.jboss.org/browse/JASSIST-205
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: jdk1.7.0_21, Win8amd64
> Reporter: Ryan Kenney
> Assignee: Shigeru Chiba
> Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> /**************************************************************************
> * Demonstrates an "Inconsistent stackmap frames" exception that results
> * from PowerMock 1.5 and JDK 7.
> *************************************************************************/
> @Test
> public void testWaitForExitMockMonitors() throws InterruptedException {
> resetAll();
>
> Object mockMonitor = createStrictMock(Object.class);
> MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
>
> mockMonitor.wait(0);
> mockMonitor.notifyAll();
>
> replayAll();
>
> myClass .run();
>
> verifyAll();
> }
>
> public static class MyClassUnderTest {
> private Object m_monitor;
>
> public MyClassUnderTest(Object monitor) {
> m_monitor = monitor;
> }
>
> public void run() throws InterruptedException {
> m_monitor.wait(0);
> m_monitor.notifyAll();
> }
> }
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> at java.lang.Class.getMethods(Class.java:1429)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1803) Failure to undo a patching process which fails
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1803:
----------------------------------
Summary: Failure to undo a patching process which fails
Key: WFLY-1803
URL: https://issues.jboss.org/browse/WFLY-1803
Project: WildFly
Issue Type: Bug
Reporter: Jan Martiska
Assignee: Emanuel Muckenhuber
Scenario:
A patch tries to modify a misc file, but the process doesn't have write permissions for it (or some other kind of exception occurs, I can imagine an IOException when writing to files)
In this case, the patching process fails and is unable to recover - it leaves files which were patched successfully and doesn't revert them to original.
Suppose a patch modifies files f1 and f2. f1 comes first, and is patched successfully. f2 fails because of lack of permissions (by the way, the exception which causes this should appear in the log somewhere, but it doesn't!!).. f1 is not reverted back, because:
{noformat}
15:00:18,525 WARN [org.jboss.as.patching] (management-handler-thread - 4) failed to undo change (org.jboss.as.patching.metadata.ContentModification@1e5bcf80): java.io.FileNotFoundException: /home/jmartisk/Workspace/jboss-eap/testsuite/integration/patching/target/jbossas/.installation/patches/aed03246-56a7-406b-9dd5-add81779d951/misc/f1 (No such file or directory)
at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_25]
at java.io.FileInputStream.<init>(FileInputStream.java:138) [rt.jar:1.7.0_25]
at org.jboss.as.patching.runner.PatchContentLoader.openContentStream(PatchContentLoader.java:71) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.AbstractFileTask.apply(AbstractFileTask.java:91) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.AbstractPatchingTask.execute(AbstractPatchingTask.java:139) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:300) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:278) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.cleanup(IdentityPatchContext.java:142) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchRunner.applyPatch(IdentityPatchRunner.java:86) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.PatchToolImpl.execute(PatchToolImpl.java:205) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.PatchToolImpl.applyPatch(PatchToolImpl.java:154) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.management.LocalPatchOperationStepHandler.execute(LocalPatchOperationStepHandler.java:69) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
Test for this created as NonStandardSituationsTestCase#testWritePermissionDenied
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-205?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-205:
--------------------------------------
This doesn't appear to be a dead code issue, I'll take a look at the generated code just to be sure. The attached powermockdemoDEBUG.txt is output from trying to build the demo and includes some debug prints.
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-205
> URL: https://issues.jboss.org/browse/JASSIST-205
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: jdk1.7.0_21, Win8amd64
> Reporter: Ryan Kenney
> Assignee: Shigeru Chiba
> Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> /**************************************************************************
> * Demonstrates an "Inconsistent stackmap frames" exception that results
> * from PowerMock 1.5 and JDK 7.
> *************************************************************************/
> @Test
> public void testWaitForExitMockMonitors() throws InterruptedException {
> resetAll();
>
> Object mockMonitor = createStrictMock(Object.class);
> MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
>
> mockMonitor.wait(0);
> mockMonitor.notifyAll();
>
> replayAll();
>
> myClass .run();
>
> verifyAll();
> }
>
> public static class MyClassUnderTest {
> private Object m_monitor;
>
> public MyClassUnderTest(Object monitor) {
> m_monitor = monitor;
> }
>
> public void run() throws InterruptedException {
> m_monitor.wait(0);
> m_monitor.notifyAll();
> }
> }
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> at java.lang.Class.getMethods(Class.java:1429)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months