From issues at jboss.org Mon Mar 2 04:25:49 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 2 Mar 2015 04:25:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2346) CMRIntegrationTest deployment failed because of Weld In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2346: ---------------------------------- Priority: Blocker (was: Major) > CMRIntegrationTest deployment failed because of Weld > ---------------------------------------------------- > > Key: JBTM-2346 > URL: https://issues.jboss.org/browse/JBTM-2346 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/758/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.077 sec <<< FAILURE! > com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest Time elapsed: 16.075 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.client.ContainerEventController.execute(ContainerEventController.java:101) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.createClassContext(TestContextHandler.java:84) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > 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:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} > {code} > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > WARNING: Bundles path is deprecated and no longer used. > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > INFO: Starting container with: [/usr/local/jdk1.7.0_51/bin/java, -D[Standalone], -Xms64m, -Xmx512m, -XX:MaxPermSize=512m, -Djava.net.preferIPv4Stack=true, -server, -Xmx1024m, -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n, -ea, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.modules.system.pkgs=org.jboss.byteman, -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log/server.log, -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration/logging.properties, -jar, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/jboss-modules.jar, -mp, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone, -Djboss.server.log.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log, -Djboss.server.config.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration, -c=standalone-cmr.xml] > Listening for transport dt_socket at address: 8787 > 18:54:40,441 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final > 18:54:41,291 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final > 18:54:41,487 WARN [org.jboss.as.warn.fd-limit] (main) WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended > 18:54:41,567 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting > 18:54:44,597 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 14) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version! > 18:54:44,837 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 18:54:44,867 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.0.Final > 18:54:44,886 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.0.Final > 18:54:44,928 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.7.Final > 18:54:45,053 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 37) WFLYCLINF0001: Activating Infinispan subsystem. > 18:54:45,135 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) WFLYNAM0001: Activating Naming Subsystem > 18:54:45,130 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 43) WFLYJSF0007: Activated the following JSF Implementations: [main] > 18:54:45,226 INFO [org.jboss.as.security] (ServerService Thread Pool -- 51) WFLYSEC0002: Activating Security Subsystem > 18:54:45,281 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 18:54:45,296 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 32) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 18:54:45,214 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 52) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 18:54:45,957 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 36) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > 18:54:46,288 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) WFLYWS0002: Activating WebServices Extension > 18:54:46,312 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.2.Final) > 18:54:46,577 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.0.Beta2 > 18:54:46,600 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > 18:54:46,610 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 18:54:48,054 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 18:54:48,063 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,065 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,112 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > 18:54:48,170 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 18:54:48,172 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0014: Creating file handler for path /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/welcome-content > 18:54:48,183 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > 18:54:48,733 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta3 > 18:54:49,074 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/deployments > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 18:54:49,767 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) started in 10128ms - Started 203 of 380 services (210 services are lazy, passive or on-demand) > 18:54:50,870 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/be/d1c9cd47a4d9b1119731defb4991fec5b863c8/content > 18:54:50,895 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 18:54:51,851 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 18:54:51,852 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jboss-transaction-spi:main") which may be changed or removed in future versions without notice. > 18:54:51,905 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.war > 18:54:51,995 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 18:54:52,703 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: test.war > 18:54:52,748 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.9 (Final) > 18:54:52,868 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment test.war > 18:54:54,097 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "javax/sql/PooledConnection" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > ... 3 more > 18:54:54,181 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,191 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,221 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0010: Stopping weld service for deployment test.war > 18:54:54,294 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 91ms > 18:54:54,298 INFO [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 7 more ] > service jboss.deployment.unit."test.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 6 more ] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START, WFLYCTL0208: ... and 4 more ] > service jboss.server.global-request-controller.control-point."test.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."test.war".WeldStartService > 18:54:54,377 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0211: Suspending server > 18:54:54,390 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. > 18:54:54,398 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 18:54:54,406 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > 18:54:54,480 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 > 18:54:54,797 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.2.0.Beta8 stopping > 18:54:54,865 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) stopped in 423ms >  > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 2 04:25:49 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 2 Mar 2015 04:25:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2346) CMRIntegrationTest deployment failed because of Weld In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045109#comment-13045109 ] Gytis Trikleris commented on JBTM-2346: --------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/760/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/761/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/762/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ > CMRIntegrationTest deployment failed because of Weld > ---------------------------------------------------- > > Key: JBTM-2346 > URL: https://issues.jboss.org/browse/JBTM-2346 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/758/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.077 sec <<< FAILURE! > com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest Time elapsed: 16.075 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.client.ContainerEventController.execute(ContainerEventController.java:101) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.createClassContext(TestContextHandler.java:84) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > 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:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} > {code} > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > WARNING: Bundles path is deprecated and no longer used. > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > INFO: Starting container with: [/usr/local/jdk1.7.0_51/bin/java, -D[Standalone], -Xms64m, -Xmx512m, -XX:MaxPermSize=512m, -Djava.net.preferIPv4Stack=true, -server, -Xmx1024m, -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n, -ea, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.modules.system.pkgs=org.jboss.byteman, -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log/server.log, -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration/logging.properties, -jar, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/jboss-modules.jar, -mp, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone, -Djboss.server.log.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log, -Djboss.server.config.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration, -c=standalone-cmr.xml] > Listening for transport dt_socket at address: 8787 > 18:54:40,441 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final > 18:54:41,291 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final > 18:54:41,487 WARN [org.jboss.as.warn.fd-limit] (main) WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended > 18:54:41,567 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting > 18:54:44,597 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 14) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version! > 18:54:44,837 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 18:54:44,867 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.0.Final > 18:54:44,886 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.0.Final > 18:54:44,928 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.7.Final > 18:54:45,053 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 37) WFLYCLINF0001: Activating Infinispan subsystem. > 18:54:45,135 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) WFLYNAM0001: Activating Naming Subsystem > 18:54:45,130 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 43) WFLYJSF0007: Activated the following JSF Implementations: [main] > 18:54:45,226 INFO [org.jboss.as.security] (ServerService Thread Pool -- 51) WFLYSEC0002: Activating Security Subsystem > 18:54:45,281 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 18:54:45,296 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 32) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 18:54:45,214 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 52) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 18:54:45,957 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 36) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > 18:54:46,288 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) WFLYWS0002: Activating WebServices Extension > 18:54:46,312 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.2.Final) > 18:54:46,577 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.0.Beta2 > 18:54:46,600 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > 18:54:46,610 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 18:54:48,054 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 18:54:48,063 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,065 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,112 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > 18:54:48,170 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 18:54:48,172 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0014: Creating file handler for path /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/welcome-content > 18:54:48,183 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > 18:54:48,733 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta3 > 18:54:49,074 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/deployments > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 18:54:49,767 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) started in 10128ms - Started 203 of 380 services (210 services are lazy, passive or on-demand) > 18:54:50,870 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/be/d1c9cd47a4d9b1119731defb4991fec5b863c8/content > 18:54:50,895 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 18:54:51,851 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 18:54:51,852 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jboss-transaction-spi:main") which may be changed or removed in future versions without notice. > 18:54:51,905 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.war > 18:54:51,995 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 18:54:52,703 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: test.war > 18:54:52,748 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.9 (Final) > 18:54:52,868 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment test.war > 18:54:54,097 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "javax/sql/PooledConnection" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > ... 3 more > 18:54:54,181 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,191 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,221 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0010: Stopping weld service for deployment test.war > 18:54:54,294 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 91ms > 18:54:54,298 INFO [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 7 more ] > service jboss.deployment.unit."test.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 6 more ] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START, WFLYCTL0208: ... and 4 more ] > service jboss.server.global-request-controller.control-point."test.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."test.war".WeldStartService > 18:54:54,377 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0211: Suspending server > 18:54:54,390 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. > 18:54:54,398 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 18:54:54,406 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > 18:54:54,480 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 > 18:54:54,797 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.2.0.Beta8 stopping > 18:54:54,865 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) stopped in 423ms >  > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 2 07:12:50 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 2 Mar 2015 07:12:50 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2300) XATMI implemenation tests failed due to HornetQ disconnection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2300: -------------------------------- Summary: XATMI implemenation tests failed due to HornetQ disconnection (was: XATMI implemenation tests failed) > XATMI implemenation tests failed due to HornetQ disconnection > ------------------------------------------------------------- > > Key: JBTM-2300 > URL: https://issues.jboss.org/browse/JBTM-2300 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/694/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/consoleFull -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 2 07:58:49 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 2 Mar 2015 07:58:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2300) XATMI implemenation tests failed due to HornetQ disconnection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2300: ---------------------------------- Description: http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/753/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux64el7/ (was: http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/694/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/consoleFull ) > XATMI implemenation tests failed due to HornetQ disconnection > ------------------------------------------------------------- > > Key: JBTM-2300 > URL: https://issues.jboss.org/browse/JBTM-2300 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/753/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux64el7/ -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 11:12:49 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 3 Mar 2015 11:12:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2346) CMRIntegrationTest deployment failed because of Weld In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2346: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/809 > CMRIntegrationTest deployment failed because of Weld > ---------------------------------------------------- > > Key: JBTM-2346 > URL: https://issues.jboss.org/browse/JBTM-2346 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/758/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.077 sec <<< FAILURE! > com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest Time elapsed: 16.075 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.client.ContainerEventController.execute(ContainerEventController.java:101) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.createClassContext(TestContextHandler.java:84) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > 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:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} > {code} > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > WARNING: Bundles path is deprecated and no longer used. > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > INFO: Starting container with: [/usr/local/jdk1.7.0_51/bin/java, -D[Standalone], -Xms64m, -Xmx512m, -XX:MaxPermSize=512m, -Djava.net.preferIPv4Stack=true, -server, -Xmx1024m, -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n, -ea, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.modules.system.pkgs=org.jboss.byteman, -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log/server.log, -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration/logging.properties, -jar, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/jboss-modules.jar, -mp, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone, -Djboss.server.log.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log, -Djboss.server.config.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration, -c=standalone-cmr.xml] > Listening for transport dt_socket at address: 8787 > 18:54:40,441 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final > 18:54:41,291 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final > 18:54:41,487 WARN [org.jboss.as.warn.fd-limit] (main) WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended > 18:54:41,567 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting > 18:54:44,597 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 14) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version! > 18:54:44,837 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 18:54:44,867 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.0.Final > 18:54:44,886 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.0.Final > 18:54:44,928 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.7.Final > 18:54:45,053 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 37) WFLYCLINF0001: Activating Infinispan subsystem. > 18:54:45,135 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) WFLYNAM0001: Activating Naming Subsystem > 18:54:45,130 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 43) WFLYJSF0007: Activated the following JSF Implementations: [main] > 18:54:45,226 INFO [org.jboss.as.security] (ServerService Thread Pool -- 51) WFLYSEC0002: Activating Security Subsystem > 18:54:45,281 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 18:54:45,296 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 32) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 18:54:45,214 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 52) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 18:54:45,957 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 36) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > 18:54:46,288 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) WFLYWS0002: Activating WebServices Extension > 18:54:46,312 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.2.Final) > 18:54:46,577 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.0.Beta2 > 18:54:46,600 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > 18:54:46,610 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 18:54:48,054 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 18:54:48,063 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,065 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,112 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > 18:54:48,170 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 18:54:48,172 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0014: Creating file handler for path /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/welcome-content > 18:54:48,183 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > 18:54:48,733 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta3 > 18:54:49,074 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/deployments > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 18:54:49,767 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) started in 10128ms - Started 203 of 380 services (210 services are lazy, passive or on-demand) > 18:54:50,870 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/be/d1c9cd47a4d9b1119731defb4991fec5b863c8/content > 18:54:50,895 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 18:54:51,851 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 18:54:51,852 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jboss-transaction-spi:main") which may be changed or removed in future versions without notice. > 18:54:51,905 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.war > 18:54:51,995 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 18:54:52,703 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: test.war > 18:54:52,748 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.9 (Final) > 18:54:52,868 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment test.war > 18:54:54,097 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "javax/sql/PooledConnection" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > ... 3 more > 18:54:54,181 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,191 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,221 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0010: Stopping weld service for deployment test.war > 18:54:54,294 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 91ms > 18:54:54,298 INFO [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 7 more ] > service jboss.deployment.unit."test.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 6 more ] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START, WFLYCTL0208: ... and 4 more ] > service jboss.server.global-request-controller.control-point."test.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."test.war".WeldStartService > 18:54:54,377 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0211: Suspending server > 18:54:54,390 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. > 18:54:54,398 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 18:54:54,406 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > 18:54:54,480 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 > 18:54:54,797 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.2.0.Beta8 stopping > 18:54:54,865 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) stopped in 423ms >  > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 05:36:49 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 4 Mar 2015 05:36:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2346) CMRIntegrationTest deployment failed because of Weld In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2346: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > CMRIntegrationTest deployment failed because of Weld > ---------------------------------------------------- > > Key: JBTM-2346 > URL: https://issues.jboss.org/browse/JBTM-2346 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/758/PROFILE=MAIN,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.077 sec <<< FAILURE! > com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest Time elapsed: 16.075 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.client.ContainerEventController.execute(ContainerEventController.java:101) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.createClassContext(TestContextHandler.java:84) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > 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:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} > {code} > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > WARNING: Bundles path is deprecated and no longer used. > Feb 24, 2015 6:54:39 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal > INFO: Starting container with: [/usr/local/jdk1.7.0_51/bin/java, -D[Standalone], -Xms64m, -Xmx512m, -XX:MaxPermSize=512m, -Djava.net.preferIPv4Stack=true, -server, -Xmx1024m, -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n, -ea, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.modules.system.pkgs=org.jboss.byteman, -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log/server.log, -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration/logging.properties, -jar, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/jboss-modules.jar, -mp, /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT, -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone, -Djboss.server.log.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/log, -Djboss.server.config.dir=/home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/configuration, -c=standalone-cmr.xml] > Listening for transport dt_socket at address: 8787 > 18:54:40,441 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final > 18:54:41,291 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final > 18:54:41,487 WARN [org.jboss.as.warn.fd-limit] (main) WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended > 18:54:41,567 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting > 18:54:44,597 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 14) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version! > 18:54:44,837 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 18:54:44,867 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.0.Final > 18:54:44,886 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.0.Final > 18:54:44,928 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.7.Final > 18:54:45,053 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 37) WFLYCLINF0001: Activating Infinispan subsystem. > 18:54:45,135 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) WFLYNAM0001: Activating Naming Subsystem > 18:54:45,130 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 43) WFLYJSF0007: Activated the following JSF Implementations: [main] > 18:54:45,226 INFO [org.jboss.as.security] (ServerService Thread Pool -- 51) WFLYSEC0002: Activating Security Subsystem > 18:54:45,281 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 18:54:45,296 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 32) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 18:54:45,214 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 52) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 18:54:45,957 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 36) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > 18:54:46,288 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) WFLYWS0002: Activating WebServices Extension > 18:54:46,312 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.2.Final) > 18:54:46,577 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.0.Beta2 > 18:54:46,600 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > 18:54:46,610 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 18:54:48,054 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 18:54:48,063 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,065 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0003: Undertow 1.2.0.Beta8 starting > 18:54:48,112 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > 18:54:48,170 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 18:54:48,172 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) WFLYUT0014: Creating file handler for path /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/welcome-content > 18:54:48,183 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > 18:54:48,733 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta3 > 18:54:49,074 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/deployments > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 18:54:49,766 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 18:54:49,767 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) started in 10128ms - Started 203 of 380 services (210 services are lazy, passive or on-demand) > 18:54:50,870 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/MAIN/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/be/d1c9cd47a4d9b1119731defb4991fec5b863c8/content > 18:54:50,895 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 18:54:51,851 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 18:54:51,852 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jboss-transaction-spi:main") which may be changed or removed in future versions without notice. > 18:54:51,905 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.war > 18:54:51,995 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 18:54:52,703 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: test.war > 18:54:52,748 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.9 (Final) > 18:54:52,868 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment test.war > 18:54:54,097 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "javax/sql/PooledConnection" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > ... 3 more > 18:54:54,181 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,191 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > 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:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:97) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:79) > at org.jboss.weld.injection.ObserverMethodInvocationStrategy$2.notify(ObserverMethodInvocationStrategy.java:89) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:262) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:217) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:204) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:120) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42) > at org.jboss.weld.bootstrap.events.AbstractProcessInjectionTarget.fire(AbstractProcessInjectionTarget.java:33) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessInjectionTarget(ContainerLifecycleEvents.java:249) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:138) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireBeanEvents(AbstractBeanDeployer.java:128) > at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:322) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:273) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:406) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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:744) > Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name \"javax/sql/PooledConnection\" > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) > at java.lang.Class.privateGetPublicMethods(Class.java:2651) > at java.lang.Class.privateGetPublicMethods(Class.java:2661) > at java.lang.Class.getMethods(Class.java:1467) > at org.jboss.resteasy.cdi.Utils.isJaxrsAnnotatedClass(Utils.java:39) > at org.jboss.resteasy.cdi.Utils.isJaxrsResource(Utils.java:63) > at org.jboss.resteasy.cdi.Utils.isJaxrsComponent(Utils.java:85) > at org.jboss.resteasy.cdi.ResteasyCdiExtension.observeInjectionTarget(ResteasyCdiExtension.java:169) > 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:606) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:89) > ... 26 more > "}} > 18:54:54,221 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0010: Stopping weld service for deployment test.war > 18:54:54,294 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 91ms > 18:54:54,298 INFO [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 7 more ] > service jboss.deployment.unit."test.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, WFLYCTL0208: ... and 6 more ] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."test.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START, service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START, WFLYCTL0208: ... and 4 more ] > service jboss.server.global-request-controller.control-point."test.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./test.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."test.war".WeldStartService > 18:54:54,377 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0211: Suspending server > 18:54:54,390 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. > 18:54:54,398 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 18:54:54,406 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > 18:54:54,480 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > 18:54:54,501 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 > 18:54:54,797 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.2.0.Beta8 stopping > 18:54:54,865 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) stopped in 423ms >  > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 08:07:50 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 08:07:50 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2347: -------------------------------------- Summary: Make JMH perf benchmark failure threshold configurable Key: JBTM-2347 URL: https://issues.jboss.org/browse/JBTM-2347 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Performance Testing Affects Versions: 5.0.4 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.0.5 The PERF profile for PR testing (added in JBTM-2337) fails a job if the performance of any test degrades by more than 10%. The threshold needs to be configurable. Additionally change test com.hp.mwtests.ts.arjuna.performance.Performance1 so that it does at least some work (the test is so trivial that it's possibly prone to anomalous timings). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 11:20:48 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 11:20:48 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2348) Add a CI job PR testing of the benchmark performance repo In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2348: -------------------------------------- Summary: Add a CI job PR testing of the benchmark performance repo Key: JBTM-2348 URL: https://issues.jboss.org/browse/JBTM-2348 Project: JBoss Transaction Manager Issue Type: Feature Request Reporter: Michael Musgrove Assignee: Michael Musgrove There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 11:21:49 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 11:21:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2348) No CI job for testing git pull requests against the benchmark perf repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2348: ----------------------------------- Summary: No CI job for testing git pull requests against the benchmark perf repo (was: Add a CI job PR testing of the benchmark performance repo) > No CI job for testing git pull requests against the benchmark perf repo > ----------------------------------------------------------------------- > > Key: JBTM-2348 > URL: https://issues.jboss.org/browse/JBTM-2348 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 13:23:48 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 13:23:48 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2347: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/performance/pull/5 > Make JMH perf benchmark failure threshold configurable > ------------------------------------------------------ > > Key: JBTM-2347 > URL: https://issues.jboss.org/browse/JBTM-2347 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Performance Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > The PERF profile for PR testing (added in JBTM-2337) fails a job if the performance of any test degrades by more than 10%. The threshold needs to be configurable. > Additionally change test com.hp.mwtests.ts.arjuna.performance.Performance1 so that it does at least some work (the test is so trivial that it's possibly prone to anomalous timings). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 13:24:49 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 13:24:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2348) No CI job for testing git pull requests against the benchmark perf repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2348. ------------------------------------ Resolution: Done The new CI job is btny-pulls-benchmark (and the poller btny-pulls-benchmark-poller) > No CI job for testing git pull requests against the benchmark perf repo > ----------------------------------------------------------------------- > > Key: JBTM-2348 > URL: https://issues.jboss.org/browse/JBTM-2348 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 13:27:49 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Mar 2015 13:27:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2347: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make JMH perf benchmark failure threshold configurable > ------------------------------------------------------ > > Key: JBTM-2347 > URL: https://issues.jboss.org/browse/JBTM-2347 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Performance Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > The PERF profile for PR testing (added in JBTM-2337) fails a job if the performance of any test degrades by more than 10%. The threshold needs to be configurable. > Additionally change test com.hp.mwtests.ts.arjuna.performance.Performance1 so that it does at least some work (the test is so trivial that it's possibly prone to anomalous timings). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 5 04:03:49 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 5 Mar 2015 04:03:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2349) CompensationContext is destroyed once the first handler is invoked In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2349: ------------------------------------- Summary: CompensationContext is destroyed once the first handler is invoked Key: JBTM-2349 URL: https://issues.jboss.org/browse/JBTM-2349 Project: JBoss Transaction Manager Issue Type: Bug Components: TXFramework Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical Fix For: 5.0.5 https://github.com/jbosstm/narayana/blob/master/compensations/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java#L95 https://github.com/jbosstm/narayana/blob/master/compensations/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java#L118 If there are two handlers (compensation or confirmation), which need to access the same compensation scoped object, only the first one will succeed. Once the first handler is invoked from the ParticipantImpl, CompensationScope is destroyed. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 03:38:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 03:38:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: Tomasz Krakowiak created JBTM-2350: -------------------------------------- Summary: CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) Key: JBTM-2350 URL: https://issues.jboss.org/browse/JBTM-2350 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.0.4, 5.0.3, 5.0.2, 5.0.1, 5.0.0 Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X Reporter: Tomasz Krakowiak Assignee: Tom Jenkinson The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean (beanA) with single method annotated transactional (beanA.transactional()). This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. Both threads call beanA.transactional() at the same time. What may happen: 1. Thread 1 - enters method beanA.transactional. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method beanB.transactional. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method beanA.transactional Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 03:51:49 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 6 Mar 2015 03:51:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046894#comment-13046894 ] Michael Musgrove commented on JBTM-2350: ---------------------------------------- Do you have a test case for this? I guess the easy fix is to make TransactionalInterceptorBase#previousUserTransactionAvailability a thread local too. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 04:12:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 04:12:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046902#comment-13046902 ] Tomasz Krakowiak commented on JBTM-2350: ---------------------------------------- Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it by hacking in SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 04:12:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 04:12:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046902#comment-13046902 ] Tomasz Krakowiak edited comment on JBTM-2350 at 3/6/15 4:12 AM: ---------------------------------------------------------------- Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it and hacked in my SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. was (Author: niematojaktomasz): Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it by hacking in SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 04:20:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 04:20:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Krakowiak updated JBTM-2350: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/811 > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 04:32:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 04:32:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Krakowiak updated JBTM-2350: ----------------------------------- Description: The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. Both threads call `beanA.transactional()` at the same time. What may happen: 1. Thread 1 - enters method `beanA.transactional()`. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method `beanA.transactional()`. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method `beanA.transactional()` Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) was: The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean (beanA) with single method annotated transactional (beanA.transactional()). This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. Both threads call beanA.transactional() at the same time. What may happen: 1. Thread 1 - enters method beanA.transactional. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method beanB.transactional. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method beanA.transactional Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 6 04:53:49 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Fri, 6 Mar 2015 04:53:49 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046916#comment-13046916 ] Tomasz Krakowiak commented on JBTM-2350: ---------------------------------------- [~mmusgrov] Thread local wouldn't work correctly if interceptor would be called recursively. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Mar 8 06:11:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 8 Mar 2015 06:11:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit failed In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2351: ----------------------------------- Summary: com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit failed Key: JBTM-2351 URL: https://issues.jboss.org/browse/JBTM-2351 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Tom Jenkinson Assignee: Paul Robinson Fix For: 5.0.5 http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Mar 8 06:11:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 8 Mar 2015 06:11:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2351: ----------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit failed > ------------------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 05:29:19 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 9 Mar 2015 05:29:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2351: ---------------------------------- Summary: XTS qa tests fail to stop WildFly after excecution (was: com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit failed) > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 05:30:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 9 Mar 2015 05:30:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047276#comment-13047276 ] Gytis Trikleris commented on JBTM-2351: --------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/767/PROFILE=XTS,jdk=jdk7.latest,label=linux/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/768/PROFILE=XTS,jdk=jdk7.latest,label=linux/ > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 09:46:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Mar 2015 09:46:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2350: ----------------------------------- Fix Version/s: 5.0.5 > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > Fix For: 5.0.5 > > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 12:32:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Mar 2015 12:32:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2350: -------------------------------------- Assignee: Tomasz Krakowiak (was: Tom Jenkinson) > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tomasz Krakowiak > Fix For: 5.0.5 > > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 12:36:19 2015 From: issues at jboss.org (Tomasz Krakowiak (JIRA)) Date: Mon, 9 Mar 2015 12:36:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Krakowiak resolved JBTM-2350. ------------------------------------ Resolution: Done > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tomasz Krakowiak > Fix For: 5.0.5 > > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 06:11:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 10 Mar 2015 06:11:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048490#comment-13048490 ] Gytis Trikleris commented on JBTM-2351: --------------------------------------- Looks like this depends on the environment. Does not fail on my machine, but fails on Jaime quite regularly. However, failure appears on different tests, thus have to execute all XTS crash recovery test suite. > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 11 08:12:18 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 11 Mar 2015 08:12:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2345) Off image storage for docker transaction service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048880#comment-13048880 ] Mark Little commented on JBTM-2345: ----------------------------------- BTW whilst the base docker image is immutable, if you make changes to a running instance then they will be saved but under a new image id (unless you run with the -rm option). So it's not quite as bad as we may have thought, i.e., as long as we tell the developer/user that they need to rerun with the new image id, they will see transaction logs between instantiations. https://gist.github.com/goldmann/b547c230e402d702a140 > Off image storage for docker transaction service > ------------------------------------------------ > > Key: JBTM-2345 > URL: https://issues.jboss.org/browse/JBTM-2345 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Build System, Cloud, JTS > Affects Versions: 5.0.4 > Reporter: Mark Little > Assignee: Tom Jenkinson > Labels: docker > > Now we have a docker image for JTS we need to look at making the state available after the image(s) go away. Remember that docker produces immutable images, so any state change that occurs within the running instance will be lost when the image dies, is taken out of service etc. Currently the docker image for JTS we have will store all of the transaction log information within the image, which is fine for testing purposes but not for a running deployment. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 11 09:53:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 11 Mar 2015 09:53:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2349) CompensationContext is destroyed once the first handler is invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2349: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/813 > CompensationContext is destroyed once the first handler is invoked > ------------------------------------------------------------------ > > Key: JBTM-2349 > URL: https://issues.jboss.org/browse/JBTM-2349 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 5.0.5 > > > https://github.com/jbosstm/narayana/blob/master/compensations/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java#L95 > https://github.com/jbosstm/narayana/blob/master/compensations/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java#L118 > If there are two handlers (compensation or confirmation), which need to access the same compensation scoped object, only the first one will succeed. Once the first handler is invoked from the ParticipantImpl, CompensationScope is destroyed. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 05:05:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 12 Mar 2015 05:05:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2245: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 05:05:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 12 Mar 2015 05:05:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2245: -------------------------------- Fix Version/s: 5.0.5 (was: 5.x.y) > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 05:09:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 12 Mar 2015 05:09:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2245: -------------------------------- Forum Reference: https://developer.jboss.org/thread/252905 > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 05:09:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 12 Mar 2015 05:09:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2245: -------------------------------- Component/s: XTS > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration, XTS > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 10:33:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 12 Mar 2015 10:33:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049421#comment-13049421 ] Gytis Trikleris commented on JBTM-2351: --------------------------------------- Log entries indicating the cause of the problem: WS-AT: {code} WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 {code} WS-BA: {code} WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046044: no XTS application recovery module found to help reactivate recovered WS-BA participant org.jboss.jbossts.xts.servicetests.CoordinatorCompletionParticipant.0 {code} > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 10:33:19 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 12 Mar 2015 10:33:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049421#comment-13049421 ] Gytis Trikleris edited comment on JBTM-2351 at 3/12/15 10:33 AM: ----------------------------------------------------------------- Log entries indicating the cause of the problem: WS-AT: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 WS-BA: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046044: no XTS application recovery module found to help reactivate recovered WS-BA participant org.jboss.jbossts.xts.servicetests.CoordinatorCompletionParticipant.0 was (Author: gytis): Log entries indicating the cause of the problem: WS-AT: {code} WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 {code} WS-BA: {code} WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046044: no XTS application recovery module found to help reactivate recovered WS-BA participant org.jboss.jbossts.xts.servicetests.CoordinatorCompletionParticipant.0 {code} > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 12 11:48:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 12 Mar 2015 11:48:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049421#comment-13049421 ] Gytis Trikleris edited comment on JBTM-2351 at 3/12/15 11:47 AM: ----------------------------------------------------------------- Log entries indicating the cause of the problem: WS-AT: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 WS-BA: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046044: no XTS application recovery module found to help reactivate recovered WS-BA participant org.jboss.jbossts.xts.servicetests.CoordinatorCompletionParticipant.0 And common deployment error: {code} ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."xtstest.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xtstest.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "xtstest.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 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:744) Caused by: java.lang.NullPointerException at org.jboss.ws.common.configuration.AbstractCommonConfigResolver.resolveEndpointConfig(AbstractCommonConfigResolver.java:129) at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER.processAnnotation(WSIntegrationProcessorJAXWS_HANDLER.java:95) at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) ... 5 more {code} was (Author: gytis): Log entries indicating the cause of the problem: WS-AT: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 WS-BA: WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046044: no XTS application recovery module found to help reactivate recovered WS-BA participant org.jboss.jbossts.xts.servicetests.CoordinatorCompletionParticipant.0 > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 06:07:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Mar 2015 06:07:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if a DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2352: -------------------------------------- Summary: JDBC test suite fails if a DataSource does not implement javax.sql.DataSource Key: JBTM-2352 URL: https://issues.jboss.org/browse/JBTM-2352 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.0.4 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.0.5 I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.transaction: {code} ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) {code} In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 06:18:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Mar 2015 06:18:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2352: ----------------------------------- Summary: JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource (was: JDBC test suite fails if a DataSource does not implement javax.sql.DataSource) > JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource > --------------------------------------------------------------------------------- > > Key: JBTM-2352 > URL: https://issues.jboss.org/browse/JBTM-2352 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.transaction: > {code} > ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) > 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) > {code} > In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 06:18:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Mar 2015 06:18:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2352: ----------------------------------- Description: I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.DataSource: {code} ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) {code} In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. was: I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.transaction: {code} ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) {code} In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. > JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource > --------------------------------------------------------------------------------- > > Key: JBTM-2352 > URL: https://issues.jboss.org/browse/JBTM-2352 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.DataSource: > {code} > ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) > 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) > {code} > In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 06:24:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 13 Mar 2015 06:24:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049779#comment-13049779 ] Tom Jenkinson commented on JBTM-2352: ------------------------------------- Hi Mike, I have an observation. That test appears to be using a JDBC object store rather than just using the database as an XAResource. I think the test you might be trying to do is to verify the XAResource for recovery rather than test it as the JDBCStore? > JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource > --------------------------------------------------------------------------------- > > Key: JBTM-2352 > URL: https://issues.jboss.org/browse/JBTM-2352 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.DataSource: > {code} > ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) > 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) > {code} > In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 07:43:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Mar 2015 07:43:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049804#comment-13049804 ] Michael Musgrove commented on JBTM-2352: ---------------------------------------- Yes I had configured a JDBC object store test to use an XA datasource. I have changed the config to use com.impossibl.postgres.jdbc.PGDataSource instead. > JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource > --------------------------------------------------------------------------------- > > Key: JBTM-2352 > URL: https://issues.jboss.org/browse/JBTM-2352 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.DataSource: > {code} > ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) > 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) > {code} > In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 07:43:20 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Mar 2015 07:43:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2352) JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2352. ------------------------------------ Resolution: Rejected Rejecting because the failure is due to a configuration error. > JDBC test suite fails if an XA DataSource does not implement javax.sql.DataSource > --------------------------------------------------------------------------------- > > Key: JBTM-2352 > URL: https://issues.jboss.org/browse/JBTM-2352 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > I tried testing a new JDBC driver with the qa test suite. The test fail unless the XA DataSource implements javax.sql.DataSource: > {code} > ccessors.DynamicDataSourceJDBCAccess at 61d38439 : java.lang.ClassCastException: com.impossibl.postgres.jdbc.xa.PGXADataSource cannot be cast to javax.sql.DataSource > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess.initialise(DynamicDataSourceJDBCAccess.java:84) > 2015-03-12 14:21:08,176 err: 2015-03-12 14:21:08.176 FINE POA RootPOA... done > 2015-03-12 14:21:08,176 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.(JDBCStore.java:214) > {code} > In addition the jdbc testsuite only works with XADataSources that implement javax.naming.Referenceable. As part of the fix we should investigate whether using com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection will remove this restriction. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 08:09:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 13 Mar 2015 08:09:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2351) XTS qa tests fail to stop WildFly after excecution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049818#comment-13049818 ] Gytis Trikleris commented on JBTM-2351: --------------------------------------- This WildFly update is causing the issue: https://github.com/wildfly/wildfly/commit/c0c1e82d8472e1b29c679380d5e0aeaf73c49735#diff-5fd0de2763a715d56ad571513a389192 > XTS qa tests fail to stop WildFly after excecution > -------------------------------------------------- > > Key: JBTM-2351 > URL: https://issues.jboss.org/browse/JBTM-2351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/179/console -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 08:21:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 13 Mar 2015 08:21:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Fix Version/s: 5.x.y (was: 6.x.y) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.x.y > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 11:00:24 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 13 Mar 2015 11:00:24 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/754 > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.x.y > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:25:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 08:25:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027323#comment-13027323 ] Tom Jenkinson edited comment on JBTM-2203 at 3/16/15 8:24 AM: -------------------------------------------------------------- I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on JBTM-2206 (note it does not have an effect on the API of StateManager). was (Author: tomjenkinson): I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on JBTM-2206 (note it does have an effect on the API of StateManager). > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:42:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 08:42:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2203: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/794 (was: https://github.com/jbosstm/narayana/pull/680) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:43:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 08:43:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027323#comment-13027323 ] Tom Jenkinson edited comment on JBTM-2203 at 3/16/15 8:42 AM: -------------------------------------------------------------- I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on https://github.com/jbosstm/narayana/pull/794 (note it does not have an effect on the API of StateManager). was (Author: tomjenkinson): I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on JBTM-2206 (note it does not have an effect on the API of StateManager). > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:43:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 08:43:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027323#comment-13027323 ] Tom Jenkinson edited comment on JBTM-2203 at 3/16/15 8:43 AM: -------------------------------------------------------------- I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on https://github.com/jbosstm/narayana/pull/794 (note it does not have a minor effect on the API of StateManager as the protected state is now of a different type). was (Author: tomjenkinson): I have pulled the changes to the hashmap into a separate commit and raised a PR for it over on https://github.com/jbosstm/narayana/pull/794 (note it does not have an effect on the API of StateManager). > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:45:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 08:45:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/807 (was: https://github.com/jbosstm/narayana/pull/679, https://github.com/jbosstm/narayana/pull/794) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 09:28:20 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Mon, 16 Mar 2015 09:28:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050471#comment-13050471 ] Mark Little commented on JBTM-2203: ----------------------------------- Hold on ... doesn't this changed the public API of StateManager and LockManager? Whilst the latter is a superset of the previous API, the former isn't and potentially breaks other classes from users that may inherit from StateManager. Did we deprecate as discussed last July? Did we determine what the cost/benefit is of doing this? > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 10:12:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Mar 2015 10:12:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050513#comment-13050513 ] Tom Jenkinson commented on JBTM-2203: ------------------------------------- Sorry, I was cleaning up the pull queue a little today hence the activity but we aren't in a position to merge these changes yet, hence why we haven't deprecated anything. The changes I made to this Jira this morning are to support investigating the benefits of merging changes in this area. The PR has the "Hold" label on it. The reason I raised a PR is so that our performance runs can work out the benefit. I modified my comment when I realized it was not accurate. > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 10:24:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Mar 2015 10:24:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050519#comment-13050519 ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- The perf profile looks for anything more than a 10% change (regression or improvement). The run did not show any "significant" change. The figures for each performance test were: {code} com.hp.mwtests.ts.arjuna.performance.Performance1.onePhase: 895697.232857 vrs 902345.326032 (change: 0) com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testThreadActionData: 437838.597325 vrs 430096.956384 (change: 0) com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testCheckedAction: 32320.338816 vrs 33034.983201 (change: 0) com.arjuna.ats.jta.xa.performance.JTAStoreTests.jtaTest: 90531.981753 vrs 89787.577741 (change: 0) com.hp.mwtests.ts.arjuna.performance.Performance1.twoPhase: 817996.341431 vrs 790490.246540 (change: 0) {code} where the first figure is the benchmark for the code being tested in the PR and the second figure is the figure for the code in the master branch > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 17 12:21:19 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Tue, 17 Mar 2015 12:21:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051079#comment-13051079 ] Mark Little commented on JBTM-2206: ----------------------------------- So no perceivable difference at all? > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 04:58:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 18 Mar 2015 04:58:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051251#comment-13051251 ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- Mike is preparing a document on how we do our performance testing to share on our dev forum and he will create a discussion around it. The reason I mention that is because it is possible (but unlikely, as one of the tests we use Mike wrote specifically for this purpose) that our suite doesn't exercise the area where the improvement would be found. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:26:20 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 18 Mar 2015 11:26:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051429#comment-13051429 ] Mark Little commented on JBTM-2206: ----------------------------------- I assume the plan is to leave things alone if there is no significant difference? http://www.phrases.org.uk/meanings/if-it-aint-broke-dont-fix-it.html > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:52:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 18 Mar 2015 11:52:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051446#comment-13051446 ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- Yes - it is. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:57:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 18 Mar 2015 11:57:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051451#comment-13051451 ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too ambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:57:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 18 Mar 2015 11:57:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051451#comment-13051451 ] Michael Musgrove edited comment on JBTM-2206 at 3/18/15 11:57 AM: ------------------------------------------------------------------ Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too unambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. was (Author: mmusgrov): Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too ambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:58:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 18 Mar 2015 11:58:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051451#comment-13051451 ] Michael Musgrove edited comment on JBTM-2206 at 3/18/15 11:57 AM: ------------------------------------------------------------------ Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too ambitiou/unambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. was (Author: mmusgrov): Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too unambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 11:58:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 18 Mar 2015 11:58:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051451#comment-13051451 ] Michael Musgrove edited comment on JBTM-2206 at 3/18/15 11:57 AM: ------------------------------------------------------------------ Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too ambitious/unambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. was (Author: mmusgrov): Yes, we will only make the change if we can demonstrate a benefit. That said, the current criteria for a performance improvement/degradation is 10% better/worse, respectively, which may be too ambitiou/unambitious, Tom suggests 0.5%. It is also possible that the benchmarks that the PR job runs will not exercise the code changes so it may be necessary for new benchmarks to be added (by us or by whoever raises the PR). The article Tom mentioned will give a fuller description of what and how we benchmark and the criteria for pass/failure. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 12:01:21 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 18 Mar 2015 12:01:21 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051455#comment-13051455 ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- I suggested 10% improvement should be required for it to be considered as an improvement - but that only 3% degradation would be needed for it to be considered that it is a performance regression. The reason I said 3% is that is the most variance I have seen on jobs that have no material effect on the code and so our environment seems to exhibit about 3% variance. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 12:15:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 18 Mar 2015 12:15:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051470#comment-13051470 ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- OK, sounds reasonable. I will tweak the job parameters to match that. We can do further tweaks as and when needed. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 09:21:20 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 19 Mar 2015 09:21:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051772#comment-13051772 ] Mark Little commented on JBTM-2206: ----------------------------------- 0.5% improvement seems way to small, so I'm happy with 10%. My concern is that we should be cautious when making changes in case we introduce bugs (not necessarily in our code but in the routines we add). 10% seems like a good point at which to say we should take a risk. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 09:42:18 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Mar 2015 09:42:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051792#comment-13051792 ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- Sure, to be clear what I have proposed is that we need to see 10% for it to be considered an improvement and if we see 3% loss we class it as a degradation. But I have asked Mike to prioritise getting his article and forum post online as it will be easier to discuss it there. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 11:07:19 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 19 Mar 2015 11:07:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2353) Compensation handler interceptors should not throw exception, if there is not transaction In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2353: ------------------------------------- Summary: Compensation handler interceptors should not throw exception, if there is not transaction Key: JBTM-2353 URL: https://issues.jboss.org/browse/JBTM-2353 Project: JBoss Transaction Manager Issue Type: Bug Components: TXFramework Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.0.5 @TXCompensate, @TXConfirm, and @TxLogged interceptors throw exception, if there is not transaction. However, transaction availability check is also done by @Compensatable interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 11:48:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 19 Mar 2015 11:48:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2353) Compensation handler interceptors should not throw exception, if there is no transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2353: ---------------------------------- Summary: Compensation handler interceptors should not throw exception, if there is no transaction (was: Compensation handler interceptors should not throw exception, if there is not transaction) > Compensation handler interceptors should not throw exception, if there is no transaction > ---------------------------------------------------------------------------------------- > > Key: JBTM-2353 > URL: https://issues.jboss.org/browse/JBTM-2353 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > @TXCompensate, @TXConfirm, and @TxLogged interceptors throw exception, if there is not transaction. However, transaction availability check is also done by @Compensatable interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 11:48:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 19 Mar 2015 11:48:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2353) Compensation handler interceptors should not throw exception, if there is no transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2353: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/816 > Compensation handler interceptors should not throw exception, if there is no transaction > ---------------------------------------------------------------------------------------- > > Key: JBTM-2353 > URL: https://issues.jboss.org/browse/JBTM-2353 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > @TXCompensate, @TXConfirm, and @TxLogged interceptors throw exception, if there is not transaction. However, transaction availability check is also done by @Compensatable interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Mar 19 12:56:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Mar 2015 12:56:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2353) Compensation handler interceptors should not throw exception, if there is no transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051914#comment-13051914 ] Tom Jenkinson commented on JBTM-2353: ------------------------------------- Did you talk to Paul about this? Is it possible to expand on the description please as its not clear. I would have expected that a TxConfirm interceptor does require a TX but maybe you are saying that check is done elsewhere? Also how did the issue crop up? > Compensation handler interceptors should not throw exception, if there is no transaction > ---------------------------------------------------------------------------------------- > > Key: JBTM-2353 > URL: https://issues.jboss.org/browse/JBTM-2353 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > @TXCompensate, @TXConfirm, and @TxLogged interceptors throw exception, if there is not transaction. However, transaction availability check is also done by @Compensatable interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 06:33:18 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 20 Mar 2015 06:33:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2353) Compensation handler interceptors should not throw exception, if there is no transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052103#comment-13052103 ] Gytis Trikleris commented on JBTM-2353: --------------------------------------- Yes, we agreed that it shouldn't do this, because it is the duty of @Compensatable handler > Compensation handler interceptors should not throw exception, if there is no transaction > ---------------------------------------------------------------------------------------- > > Key: JBTM-2353 > URL: https://issues.jboss.org/browse/JBTM-2353 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.5 > > > @TXCompensate, @TXConfirm, and @TxLogged interceptors throw exception, if there is not transaction. However, transaction availability check is also done by @Compensatable interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 11:15:21 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 20 Mar 2015 11:15:21 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052256#comment-13052256 ] Mark Little commented on JBTM-2206: ----------------------------------- Can you include a link to the forum posting here for future reference? > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 11:18:19 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 20 Mar 2015 11:18:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052259#comment-13052259 ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- I have asked Mike to - he is creating a forum topic too in order to give us a good space to discuss the article so I think he should be updating here shortly > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 12:02:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 20 Mar 2015 12:02:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2206: ----------------------------------- Forum Reference: https://developer.jboss.org/message/922334, https://community.jboss.org/message/879212 (was: https://community.jboss.org/message/879212, https://community.jboss.org/message/879212#879212) I have added a link to a forum post where we discuss how we check PRs for performance improvements and regressions > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 12:08:19 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 20 Mar 2015 12:08:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052294#comment-13052294 ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- An example PR comment for this JIRA is: https://github.com/jbosstm/narayana/pull/807#issuecomment-84053955 > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 30 06:12:18 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 30 Mar 2015 06:12:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2354) PR Checker for narayana quickstarts broken In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2354: -------------------------------------- Summary: PR Checker for narayana quickstarts broken Key: JBTM-2354 URL: https://issues.jboss.org/browse/JBTM-2354 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Testing Affects Versions: 5.0.4 Reporter: Michael Musgrove Assignee: Tom Jenkinson The quickstart PR job btny-pulls-quickstart is reporting pass when the build has actually failed. Here is an example: http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-quickstart/70 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 30 12:43:19 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 30 Mar 2015 12:43:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2355) Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT In-Reply-To: References: Message-ID: Amos Feng created JBTM-2355: ------------------------------- Summary: Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT Key: JBTM-2355 URL: https://issues.jboss.org/browse/JBTM-2355 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng Priority: Critical Fix For: 5.0.5 it has broken the narayana build http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana/787/ -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 31 09:52:19 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 31 Mar 2015 09:52:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2355) Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2355: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/820 > Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT > -------------------------------------------------- > > Key: JBTM-2355 > URL: https://issues.jboss.org/browse/JBTM-2355 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.5 > > > it has broken the narayana build > http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana/787/ -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 31 09:55:18 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 31 Mar 2015 09:55:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2355) Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2355: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade Narayana to use Wildfly 9.0.0.CR1-SNAPSHOT > -------------------------------------------------- > > Key: JBTM-2355 > URL: https://issues.jboss.org/browse/JBTM-2355 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.5 > > > it has broken the narayana build > http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana/787/ -- This message was sent by Atlassian JIRA (v6.3.11#6341)