[JBoss JIRA] (WFLY-2478) Infinispan subsystem test cases need updating
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2478:
--------------------------------------
BTW Are you planning to use the naming convention for the XMLs I suggested on Nov 15 ?
>> One possible file naming convention:
>>
>> jgroups-subsystem-current.xml
>> jgroups-subsystem-current-transform.xml
>> jgroups-subsystem-current-transform-reject{1,2,3,...}.xml
>> jgroups-subsystem-xsd-1.0.xml
>> jgroups-subsystem-xsd-1.1.xml
>
> -1 to this convention.
>
> When I tried to refactor those previously, the goals were:
>
> * no need to include "xsd" string in the xml version -- all XMLs files
> follow and XSD and they need not represent a model version
> * denote XSD version in all files: one would have to open the file to
> find the XSD version, can be easier forgotten to be bumped, and current
> would have to be renamed with every bump.
> * no dot character, use dashes instead
> * use suffix to make the name clear what is the xml file for and keep
> files ordered:
> - no suffix = subsystem parsing test
> - suffix "transformer" = accepted transformations (typically 1 file
> is enough)
> - suffix "transformer-reject" = rejected transformations (multiple
> needed)
>
> So I would suggest:
>
> <subsystem name>-subsystem-<schema version>-<suffix>.xml
>
> that would make nicely sorted list:
>
> - jgroups-subsystem-1_0.xml
> - jgroups-subsystem-1_1.xml
> - jgroups-subsystem-1_2.xml
> - jgroups-subsystem-1_2-transform.xml
> - jgroups-subsystem-1_2-transform-reject1.xml
> - jgroups-subsystem-1_2-transform-reject2.xml
> - jgroups-subsystem-1_2-transform-discard.xml
>
> Cheers,
> Rado
> Infinispan subsystem test cases need updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
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, 8 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test cases need updating
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-2478:
-------------------------------------------
TransformersTestCase has had the following changes made:
- restructured the test case so that for each legacy management api version tested against current, we test:
-- clean boot / model comparison for a configuration for which we expect no rejections
-- failed boot / expected rejections for a configuration for which we expect rejections
We perform this api test for Wildfly 8 against all legacy versions of Wildfly / JBoss AS..
Kabir has also requested that we do such testing for legacy EAP versions too, as well as the legacy AS versions and this has been included. The rationale is to catch divergence between Wildfly management api and EAP management api sooner rather than later.
> Infinispan subsystem test cases need updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
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, 8 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test cases need updating
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-2478:
-------------------------------------------
Renamed the test cases to eliminate overlap in package name and file name:
OperationSequencesTestCase
OperationsTestCase
SubsystemParsingTestCase
TransformersTestCase
> Infinispan subsystem test cases need updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
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, 8 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Frank Cornelis (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Frank Cornelis commented on WFLY-1477:
--------------------------------------
Just tested out the latest WildFly github tree. Issue still present:
Caused by: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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, 8 months
[JBoss JIRA] (JASSIST-215) CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
by Laurent GARCIA (JIRA)
[ https://issues.jboss.org/browse/JASSIST-215?page=com.atlassian.jira.plugi... ]
Laurent GARCIA updated JASSIST-215:
-----------------------------------
Description:
So the new release 3.18.1-GA with powermock is better, but if you have a switch case on an enumeration in the test, the error is still here
{code:java}
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 15 in method foo.bar.MyEnum.myMethod(Ljava/lang/String;)Lfoo/bar/MyEnum; at offset 0
at foo.bar.MyTest$1.<clinit>(MyTest.java:183)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:188)
at org.powermock.modules.agent.PowerMockClassRedefiner.redefine(PowerMockClassRedefiner.java:55)
at org.powermock.modules.agent.support.PowerMockAgentTestInitializer.redefine(PowerMockAgentTestInitializer.java:49)
at org.powermock.modules.agent.support.PowerMockAgentTestInitializer.initialize(PowerMockAgentTestInitializer.java:41)
at org.powermock.modules.testng.PowerMockObjectFactory.newInstance(PowerMockObjectFactory.java:41)
at org.testng.internal.ClassHelper.createInstance1(ClassHelper.java:387)
... 22 more
{code}
was:
So the new release 3.18.1-GA with powermock is better, but if you have a switch case on an enumeration in the test, the error is still here
> CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
> -------------------------------------------------------------------------------------------
>
> Key: JASSIST-215
> URL: https://issues.jboss.org/browse/JASSIST-215
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Environment: jdk1.7.0_25
> Reporter: Laurent GARCIA
> Assignee: Shigeru Chiba
>
> So the new release 3.18.1-GA with powermock is better, but if you have a switch case on an enumeration in the test, the error is still here
> {code:java}
> Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 15 in method foo.bar.MyEnum.myMethod(Ljava/lang/String;)Lfoo/bar/MyEnum; at offset 0
> at foo.bar.MyTest$1.<clinit>(MyTest.java:183)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:188)
> at org.powermock.modules.agent.PowerMockClassRedefiner.redefine(PowerMockClassRedefiner.java:55)
> at org.powermock.modules.agent.support.PowerMockAgentTestInitializer.redefine(PowerMockAgentTestInitializer.java:49)
> at org.powermock.modules.agent.support.PowerMockAgentTestInitializer.initialize(PowerMockAgentTestInitializer.java:41)
> at org.powermock.modules.testng.PowerMockObjectFactory.newInstance(PowerMockObjectFactory.java:41)
> at org.testng.internal.ClassHelper.createInstance1(ClassHelper.java:387)
> ... 22 more
> {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, 8 months
[JBoss JIRA] (WFLY-2539) Avoid adding dependency on batch impl to applications
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2539?page=com.atlassian.jira.plugin.... ]
Cheng Fang updated WFLY-2539:
-----------------------------
Component/s: Batch
(was: EE)
> Avoid adding dependency on batch impl to applications
> -----------------------------------------------------
>
> Key: WFLY-2539
> URL: https://issues.jboss.org/browse/WFLY-2539
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: James Perkins
>
> Ony batch api needs to be added as dependency to all deployed apps. Batch impl modules should not be exposed to application deployments.
> from IRC discussion on 11/19/2013:
> 10:57:05 - Nihility: […] currently we are stuffing batch implementation details into every module thats bad
> 10:57:29 - Nihility: cfang: jamezp_afk the only deps that a user deployment should have is on APIs
> 10:57:50 - Nihility: cfang: jamezp_afk the APIs then depend on an impl either dynamically or in their module.xml
> 10:58:55 - Nihility: cfang: jamezp_afk its ok to add the APIs to every deployment
> 10:58:55 - dmlloyd: not implementation modules
> 10:59:01 - cfang: Nihility: I recall we did come up with some coarse grained logic to reduce the impact
> 11:01:25 - dmlloyd: cfang, but the point is that the impl modules should not be on any application at all, batch or not
> 11:02:06 - Nihility: cfang: right the rule is basically a propagation rule. The user only sees what it can access, which are APIS, the APIs can see impl classes and thats isolation
> 11:02:33 - Nihility: cfang: its the reason that a user, for example can use their own XML parser
> 11:03:10 - Nihility: cfang: we have some exceptions because third party code isn't always correct
> 11:03:34 - Nihility: cfang: but we should strive for at least our code to be properly isolated. It's not urgent but it has something we need to fix
--
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, 8 months
[JBoss JIRA] (JASSIST-215) CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
by Laurent GARCIA (JIRA)
[ https://issues.jboss.org/browse/JASSIST-215?page=com.atlassian.jira.plugi... ]
Laurent GARCIA updated JASSIST-215:
-----------------------------------
Fix Version/s: (was: 3.19.0-GA)
(was: 3.18.1-GA)
Affects Version/s: 3.18.1-GA
(was: 3.18.0-GA)
Environment: jdk1.7.0_25 (was: jdk1.7.0_21, Win8amd64)
Description:
So the new release 3.18.1-GA with powermock is better, but if you have a switch case on an enumeration in the test, the error is still here
was:
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}
> CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
> -------------------------------------------------------------------------------------------
>
> Key: JASSIST-215
> URL: https://issues.jboss.org/browse/JASSIST-215
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Environment: jdk1.7.0_25
> Reporter: Laurent GARCIA
> Assignee: Shigeru Chiba
>
> So the new release 3.18.1-GA with powermock is better, but if you have a switch case on an enumeration in the test, the error is still here
--
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, 8 months
[JBoss JIRA] (JASSIST-215) CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
by Laurent GARCIA (JIRA)
Laurent GARCIA created JASSIST-215:
--------------------------------------
Summary: CLONE - "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18.1)
Key: JASSIST-215
URL: https://issues.jboss.org/browse/JASSIST-215
Project: Javassist
Issue Type: Bug
Affects Versions: 3.18.0-GA
Environment: jdk1.7.0_21, Win8amd64
Reporter: Laurent GARCIA
Assignee: Shigeru Chiba
Fix For: 3.18.1-GA, 3.19.0-GA
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, 8 months
[JBoss JIRA] (WFLY-2573) The batch subsystem does not marshall the configuration correct in some circumstances
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2573?page=com.atlassian.jira.plugin.... ]
Cheng Fang updated WFLY-2573:
-----------------------------
Assignee: James Perkins (was: Cheng Fang)
> The batch subsystem does not marshall the configuration correct in some circumstances
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2573
> URL: https://issues.jboss.org/browse/WFLY-2573
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: James Perkins
> Fix For: 8.0.0.CR1
>
>
> If the batch subsystem is created, i.e. a new domain profile, the configuration is not applied correct.
> It look like that it is partially applied 'in memory' but not persisted.
> The used commands are:
> /profile=default-web/subsystem=batch:add()
> /profile=default-web/subsystem=batch/thread-pool=batch:add(keepalive-time={time=100,unit=milliseconds},
> max-threads=10)
> The commands are running without messages, but the domain.xml looks like this
> <subsystem xmlns="urn:jboss:domain:batch:1.0">
> <job-repository>
> <in-memory/>
> </job-repository>
> </subsystem>
--
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, 8 months
[JBoss JIRA] (WFLY-2573) The batch subsystem does not marshall the configuration correct in some circumstances
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2573?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2573:
-----------------------------------
Component/s: Batch
> The batch subsystem does not marshall the configuration correct in some circumstances
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2573
> URL: https://issues.jboss.org/browse/WFLY-2573
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
>
> If the batch subsystem is created, i.e. a new domain profile, the configuration is not applied correct.
> It look like that it is partially applied 'in memory' but not persisted.
> The used commands are:
> /profile=default-web/subsystem=batch:add()
> /profile=default-web/subsystem=batch/thread-pool=batch:add(keepalive-time={time=100,unit=milliseconds},
> max-threads=10)
> The commands are running without messages, but the domain.xml looks like this
> <subsystem xmlns="urn:jboss:domain:batch:1.0">
> <job-repository>
> <in-memory/>
> </job-repository>
> </subsystem>
--
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, 8 months