[JBoss JIRA] (WFLY-1437) Cannot remove JGroups subsystem from managed domain via CLI
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-1437:
--------------------------------------
Summary: Cannot remove JGroups subsystem from managed domain via CLI
Key: WFLY-1437
URL: https://issues.jboss.org/browse/WFLY-1437
Project: WildFly
Issue Type: Bug
Components: Clustering, Domain Management
Affects Versions: 8.0.0.Alpha1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.Alpha2
Osamu Nagano reports:
"Description of problem:
In EAP 6.1 domain mode, try to create a new profile from scratch in CLI. You can add jgroups subsystem but you cannot remove it with an error message.
In standalone mode and both modes of EAP 6.0.1, you can successfully remove it.
Steps to Reproduce:
1. Start EAP 6.1 in domain mode. The default domain.xml is sufficient.
2. Connect to the DC by CLI.
3. Execute the following commands in CLI.
--
[domain@localhost:9999 /] /profile=test:add()
[domain@localhost:9999 /] /profile=test/subsystem=jgroups:add(default-stack=udp)
[domain@localhost:9999 /] /profile=test/subsystem=jgroups:remove()
--
Actual results:
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"jgroups\")]' not found"},
"rolled-back" => true
}
Expected results:
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
"
I see that the problem exists in WildFly as well.
The problem is in JGroupsSubsystemRemove:
ModelNode removeSubsystem = Util.createOperation(REMOVE, PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH));
context.addStep(removeSubsystem, new OriginalSubsystemRemoveHandler(), OperationContext.Stage.MODEL, true);
That PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH) is incorrect in a managed domain, as it doesn't include the profile element. It's correct in a standalone server.
Easy 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
13 years, 1 month
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka updated WFLY-1048:
-------------------------------
Assignee: James Perkins (was: Ondrej Zizka)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: James Perkins
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-1048:
------------------------------------
This is the latter - appender that pushes.
Log viewer is WFLY-280.
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka reassigned WFLY-1048:
----------------------------------
Assignee: Ondrej Zizka (was: James Perkins)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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
13 years, 1 month
[JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-156?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-156:
---------------------------------------
The internal memories for the Eval nodes are created "too lazily".
In fact, if the eval node is not used, the memory will not be created at all,
causing the exception when that memory has to be cleared during the rule
removal process.
It's a RETE construction bug, it will be fixed in 5.6+
> Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-156
> URL: https://issues.jboss.org/browse/DROOLS-156
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Philipp Herzig
> Assignee: Mark Proctor
> Attachments: EvalNodeDeletion.zip
>
>
> This bug is a little bit strange to explain. In some combinations the deletion of EvalConditionNodes gives an IndexOutOfBoundsException (see exception below). As consequence the rule is not correctly removed from the internal RETE representation leading to an inconsistent KnowledgeBase.
> I cannot dig it to the exact cause, but from my observation the exception comes from two factors: Number of eval nodes + an arbitrary number of other alpha and beta nodes.
> I attached a dummy mvn project with senseless dummy rules that simulates the exception. The according JUnit is TestClass.java. With the class you can do the following tests:
> 1. Run it as is --> Exception at the primary removal point
> 2. Comment out the addition of "normalRule1" at line 111 --> Exception at the secondary removal point, i.e., one deletion works but adding and deleting again, raises exception
> 3. Comment out the addition of "normalRule2" --> No Exception.
> java.lang.IndexOutOfBoundsException: index 34
> at java.util.concurrent.atomic.AtomicReferenceArray.rawIndex(AtomicReferenceArray.java:31)
> at java.util.concurrent.atomic.AtomicReferenceArray.set(AtomicReferenceArray.java:94)
> at org.drools.common.ConcurrentNodeMemories.clearNodeMemory(ConcurrentNodeMemories.java:44)
> at org.drools.common.AbstractWorkingMemory.clearNodeMemory(AbstractWorkingMemory.java:1038)
> at org.drools.reteoo.EvalConditionNode.doRemove(EvalConditionNode.java:295)
> at org.drools.common.BaseNode.remove(BaseNode.java:115)
> at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:360)
> at org.drools.common.BaseNode.remove(BaseNode.java:115)
> at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:253)
> at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:459)
> at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1099)
> at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1077)
> at org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:207)
> at code.RuleEngine.deleteRule(RuleEngine.java:272)
> at test.TestClass.test(TestClass.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> 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)
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1435) Modcluster subsystem startup missing required dependencies from JBoss Web
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1435?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-1435:
------------------------------------
Just checked against the released 8.0.0.Alpha1 version (standalone-ha.xml and standalone-full-ha.xml). It indeed is broken.
> Modcluster subsystem startup missing required dependencies from JBoss Web
> --------------------------------------------------------------------------
>
> Key: WFLY-1435
> URL: https://issues.jboss.org/browse/WFLY-1435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> The mod cluster subsystem is not starting correctly due to missing (incorrect) dependencies on JBoss Web:
> {noformat}
> 16:59:36,549 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 16:59:36,561 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> [snip]
> 16:59:36,639 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,654 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 16:59:36,657 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 16:59:36,661 INFO [org.jboss.as.mail.extension] (MSC service thread 1-8) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 16:59:36,669 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,755 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Beta1
> 16:59:36,760 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 16:59:36,771 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) JBAS010417: Started Driver service with driver-name = h2
> 16:59:36,816 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 16:59:36,839 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 16:59:36,891 INFO [io.undertow] (ServerService Thread Pool -- 51) Creating file handler for path /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/welcome-content
> 16:59:36,904 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler@26dce695.
> 16:59:36,905 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) registering handler org.jboss.msc.value.InjectedValue@ab2d3a9 under path '/'
> 16:59:36,927 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 16:59:36,926 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 16:59:37,252 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,262 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,291 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:9999
> 16:59:37,479 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/standalone/deployments
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
> 16:59:37,507 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web, jboss.web.connector.ajp]"]}
> 16:59:37,571 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.web (missing) dependents: [service jboss.mod-cluster]
> service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster]
> 16:59:37,706 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 16:59:37,707 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 16:59:37,707 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 3027ms - Started 157 of 252 services (1 services failed or missing dependencies, 116 services are lazy, passive or on-demand)
> {noformat}
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1435) Modcluster subsystem startup missing required dependencies from JBoss Web
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1435?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-1435:
------------------------------------
Is this against the release Alpha1 version or against upstream master branch? I'm curious since if this is against a released version then apparently the mod_cluster subsystem isn't functional in that release :(
> Modcluster subsystem startup missing required dependencies from JBoss Web
> --------------------------------------------------------------------------
>
> Key: WFLY-1435
> URL: https://issues.jboss.org/browse/WFLY-1435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> The mod cluster subsystem is not starting correctly due to missing (incorrect) dependencies on JBoss Web:
> {noformat}
> 16:59:36,549 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 16:59:36,561 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> [snip]
> 16:59:36,639 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,654 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 16:59:36,657 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 16:59:36,661 INFO [org.jboss.as.mail.extension] (MSC service thread 1-8) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 16:59:36,669 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,755 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Beta1
> 16:59:36,760 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 16:59:36,771 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) JBAS010417: Started Driver service with driver-name = h2
> 16:59:36,816 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 16:59:36,839 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 16:59:36,891 INFO [io.undertow] (ServerService Thread Pool -- 51) Creating file handler for path /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/welcome-content
> 16:59:36,904 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler@26dce695.
> 16:59:36,905 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) registering handler org.jboss.msc.value.InjectedValue@ab2d3a9 under path '/'
> 16:59:36,927 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 16:59:36,926 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 16:59:37,252 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,262 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,291 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:9999
> 16:59:37,479 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/standalone/deployments
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
> 16:59:37,507 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web, jboss.web.connector.ajp]"]}
> 16:59:37,571 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.web (missing) dependents: [service jboss.mod-cluster]
> service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster]
> 16:59:37,706 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 16:59:37,707 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 16:59:37,707 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 3027ms - Started 157 of 252 services (1 services failed or missing dependencies, 116 services are lazy, passive or on-demand)
> {noformat}
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1431) org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1431?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-1431:
------------------------------------
Just curious - did it start failing recently? I'm surprised that we hadn't noticed this failure anywhere else. Perhaps you just tried running InterceptorLifecycleSFSBTestCase#testInterceptorPostConstructWithProceed method? If that's the case then the test methods in that testcases are perhaps using some data left around by other test methods in that same testcase.
The fix you provided is correct. I'm just trying to figure out if other test methods in that testcase have to be reviewed too.
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1431
> URL: https://issues.jboss.org/browse/WFLY-1431
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: WFLY-1431.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed with
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase.testInterceptorPostConstructWithProceed(InterceptorLifecycleSFSBTestCase.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {noformat}
--
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
13 years, 1 month